2010-11-24 00:41:49 +00:00
|
|
|
SUMMARY = "Linux-PAM (Pluggable Authentication Modules)"
|
2012-01-12 22:11:49 +00:00
|
|
|
DESCRIPTION = "Linux-PAM (Pluggable Authentication Modules for Linux), a flexible mechanism for authenticating users"
|
|
|
|
|
HOMEPAGE = "https://fedorahosted.org/linux-pam/"
|
|
|
|
|
BUGTRACKER = "https://fedorahosted.org/linux-pam/newticket"
|
2010-11-24 00:41:49 +00:00
|
|
|
SECTION = "base"
|
|
|
|
|
# PAM is dual licensed under GPL and BSD.
|
2015-06-03 16:42:01 +00:00
|
|
|
# /etc/pam.d comes from Debian libpam-runtime in 2009-11 (at that time
|
2010-08-03 07:53:38 +00:00
|
|
|
# libpam-runtime-1.0.1 is GPLv2+), by openembedded
|
|
|
|
|
LICENSE = "GPLv2+ | BSD"
|
2012-08-18 04:56:41 +00:00
|
|
|
LIC_FILES_CHKSUM = "file://COPYING;md5=7eb5c1bf854e8881005d673599ee74d3"
|
2010-11-24 00:41:49 +00:00
|
|
|
|
2012-08-18 04:56:41 +00:00
|
|
|
SRC_URI = "http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
|
2010-08-03 07:53:38 +00:00
|
|
|
file://99_pam \
|
2013-05-29 15:09:47 +00:00
|
|
|
file://pam.d/common-account \
|
|
|
|
|
file://pam.d/common-auth \
|
|
|
|
|
file://pam.d/common-password \
|
|
|
|
|
file://pam.d/common-session \
|
|
|
|
|
file://pam.d/common-session-noninteractive \
|
|
|
|
|
file://pam.d/other \
|
2012-07-04 20:12:38 +00:00
|
|
|
file://libpam-xtests.patch \
|
2013-03-21 14:19:03 +00:00
|
|
|
file://fixsepbuild.patch \
|
2013-07-18 02:04:22 +00:00
|
|
|
file://pam-security-abstract-securetty-handling.patch \
|
|
|
|
|
file://pam-unix-nullok-secure.patch \
|
2014-09-16 03:10:57 +00:00
|
|
|
file://libpam-xtests-remove-bash-dependency.patch \
|
2015-06-03 16:42:01 +00:00
|
|
|
file://crypt_configure.patch \
|
2012-07-04 20:12:38 +00:00
|
|
|
"
|
2015-07-17 08:53:24 +00:00
|
|
|
|
2016-05-25 14:07:39 +00:00
|
|
|
SRC_URI[md5sum] = "da4b2289b7cfb19583d54e9eaaef1c3a"
|
|
|
|
|
SRC_URI[sha256sum] = "241aed1ef522f66ed672719ecf2205ec513fd0075ed80cda8e086a5b1a01d1bb"
|
2010-08-03 07:53:38 +00:00
|
|
|
|
2016-05-25 14:07:39 +00:00
|
|
|
SRC_URI_append_libc-uclibc = " file://use-utmpx.patch"
|
2015-10-16 07:45:54 +00:00
|
|
|
|
2016-05-25 14:07:39 +00:00
|
|
|
SRC_URI_append_libc-musl = " file://0001-Add-support-for-defining-missing-funcitonality.patch \
|
2015-11-19 01:04:49 +00:00
|
|
|
file://include_paths_header.patch \
|
|
|
|
|
"
|
2011-04-01 03:45:29 +00:00
|
|
|
|
2016-06-01 13:25:56 +00:00
|
|
|
DEPENDS = "bison-native flex flex-native cracklib libxml2-native"
|
2010-11-24 00:41:49 +00:00
|
|
|
|
2010-08-03 07:53:38 +00:00
|
|
|
EXTRA_OECONF = "--with-db-uniquename=_pam \
|
|
|
|
|
--includedir=${includedir}/security \
|
|
|
|
|
--libdir=${base_libdir} \
|
2012-08-03 08:21:30 +00:00
|
|
|
--disable-nis \
|
2013-09-23 16:34:01 +00:00
|
|
|
--disable-regenerate-docu \
|
|
|
|
|
--disable-prelude"
|
2012-01-12 22:11:49 +00:00
|
|
|
|
2010-08-03 07:53:38 +00:00
|
|
|
CFLAGS_append = " -fPIC "
|
|
|
|
|
|
2014-03-05 17:17:18 +00:00
|
|
|
PR = "r5"
|
2012-08-19 12:30:07 +00:00
|
|
|
|
2010-08-03 07:53:38 +00:00
|
|
|
S = "${WORKDIR}/Linux-PAM-${PV}"
|
|
|
|
|
|
2013-07-05 00:49:54 +00:00
|
|
|
inherit autotools gettext pkgconfig
|
2010-08-03 07:53:38 +00:00
|
|
|
|
2013-08-23 17:42:38 +00:00
|
|
|
PACKAGECONFIG[audit] = "--enable-audit,--disable-audit,audit,"
|
|
|
|
|
|
2011-07-19 09:08:31 +00:00
|
|
|
PACKAGES += "${PN}-runtime ${PN}-xtests"
|
2010-08-03 07:53:38 +00:00
|
|
|
FILES_${PN} = "${base_libdir}/lib*${SOLIBS}"
|
|
|
|
|
FILES_${PN}-dev += "${base_libdir}/security/*.la ${base_libdir}/*.la ${base_libdir}/lib*${SOLIBSDEV}"
|
|
|
|
|
FILES_${PN}-runtime = "${sysconfdir}"
|
2011-07-19 09:08:31 +00:00
|
|
|
FILES_${PN}-xtests = "${datadir}/Linux-PAM/xtests"
|
2010-08-03 07:53:38 +00:00
|
|
|
|
2014-08-11 20:21:44 +00:00
|
|
|
PACKAGES_DYNAMIC += "^${MLPREFIX}pam-plugin-.*"
|
2010-08-03 07:53:38 +00:00
|
|
|
|
2014-04-09 08:56:44 +00:00
|
|
|
def get_multilib_bit(d):
|
2016-12-14 21:13:04 +00:00
|
|
|
baselib = d.getVar('baselib') or ''
|
2014-04-09 08:56:44 +00:00
|
|
|
return baselib.replace('lib', '')
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
|
2014-04-09 08:56:44 +00:00
|
|
|
libpam_suffix = "suffix${@get_multilib_bit(d)}"
|
|
|
|
|
|
2014-08-11 20:21:44 +00:00
|
|
|
RPROVIDES_${PN} += "${PN}-${libpam_suffix}"
|
|
|
|
|
RPROVIDES_${PN}-runtime += "${PN}-runtime-${libpam_suffix}"
|
2014-04-09 08:56:44 +00:00
|
|
|
|
2014-08-27 15:57:08 +00:00
|
|
|
RDEPENDS_${PN}-runtime = "${PN}-${libpam_suffix} \
|
2014-08-28 23:33:20 +00:00
|
|
|
${MLPREFIX}pam-plugin-deny-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-permit-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-warn-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-unix-${libpam_suffix} \
|
2014-08-27 15:57:08 +00:00
|
|
|
"
|
|
|
|
|
RDEPENDS_${PN}-xtests = "${PN}-${libpam_suffix} \
|
2014-08-28 23:33:20 +00:00
|
|
|
${MLPREFIX}pam-plugin-access-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-debug-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-cracklib-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-pwhistory-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-succeed-if-${libpam_suffix} \
|
|
|
|
|
${MLPREFIX}pam-plugin-time-${libpam_suffix} \
|
2014-09-16 03:10:57 +00:00
|
|
|
coreutils"
|
2014-08-28 23:33:19 +00:00
|
|
|
|
|
|
|
|
# FIXME: Native suffix breaks here, disable it for now
|
|
|
|
|
RRECOMMENDS_${PN} = "${PN}-runtime-${libpam_suffix}"
|
|
|
|
|
RRECOMMENDS_${PN}_class-native = ""
|
2012-01-12 22:11:49 +00:00
|
|
|
|
2010-08-03 07:53:38 +00:00
|
|
|
python populate_packages_prepend () {
|
2012-07-11 17:33:43 +00:00
|
|
|
def pam_plugin_append_file(pn, dir, file):
|
|
|
|
|
nf = os.path.join(dir, file)
|
2016-12-14 21:13:04 +00:00
|
|
|
of = d.getVar('FILES_' + pn)
|
2012-07-11 17:33:43 +00:00
|
|
|
if of:
|
|
|
|
|
nf = of + " " + nf
|
|
|
|
|
d.setVar('FILES_' + pn, nf)
|
|
|
|
|
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
def pam_plugin_hook(file, pkg, pattern, format, basename):
|
2016-12-14 21:13:04 +00:00
|
|
|
pn = d.getVar('PN')
|
|
|
|
|
libpam_suffix = d.getVar('libpam_suffix')
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
|
2016-12-14 21:13:04 +00:00
|
|
|
rdeps = d.getVar('RDEPENDS_' + pkg)
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
if rdeps:
|
2014-08-30 10:12:49 +00:00
|
|
|
rdeps = rdeps + " " + pn + "-" + libpam_suffix
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
else:
|
2014-08-30 10:12:49 +00:00
|
|
|
rdeps = pn + "-" + libpam_suffix
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
d.setVar('RDEPENDS_' + pkg, rdeps)
|
|
|
|
|
|
2016-12-14 21:13:04 +00:00
|
|
|
provides = d.getVar('RPROVIDES_' + pkg)
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
if provides:
|
2014-04-09 08:56:44 +00:00
|
|
|
provides = provides + " " + pkg + "-" + libpam_suffix
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
else:
|
2014-04-09 08:56:44 +00:00
|
|
|
provides = pkg + "-" + libpam_suffix
|
libpam: fix multilib packaging issue for pam-plugins
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
(From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-28 09:43:08 +00:00
|
|
|
d.setVar('RPROVIDES_' + pkg, provides)
|
|
|
|
|
|
2016-12-14 21:13:04 +00:00
|
|
|
mlprefix = d.getVar('MLPREFIX') or ''
|
2017-03-17 15:53:09 +00:00
|
|
|
dvar = d.expand('${WORKDIR}/package')
|
2012-07-11 17:33:43 +00:00
|
|
|
pam_libdir = d.expand('${base_libdir}/security')
|
|
|
|
|
pam_sbindir = d.expand('${sbindir}')
|
|
|
|
|
pam_filterdir = d.expand('${base_libdir}/security/pam_filter')
|
2014-08-28 23:33:20 +00:00
|
|
|
pam_pkgname = mlprefix + 'pam-plugin%s'
|
2012-07-11 17:33:43 +00:00
|
|
|
|
2014-08-28 23:33:20 +00:00
|
|
|
do_split_packages(d, pam_libdir, '^pam(.*)\.so$', pam_pkgname,
|
|
|
|
|
'PAM plugin for %s', hook=pam_plugin_hook, extra_depends='')
|
2012-12-20 23:01:18 +00:00
|
|
|
pam_plugin_append_file('%spam-plugin-unix' % mlprefix, pam_sbindir, 'unix_chkpwd')
|
|
|
|
|
pam_plugin_append_file('%spam-plugin-unix' % mlprefix, pam_sbindir, 'unix_update')
|
|
|
|
|
pam_plugin_append_file('%spam-plugin-tally' % mlprefix, pam_sbindir, 'pam_tally')
|
|
|
|
|
pam_plugin_append_file('%spam-plugin-tally2' % mlprefix, pam_sbindir, 'pam_tally2')
|
|
|
|
|
pam_plugin_append_file('%spam-plugin-timestamp' % mlprefix, pam_sbindir, 'pam_timestamp_check')
|
|
|
|
|
pam_plugin_append_file('%spam-plugin-mkhomedir' % mlprefix, pam_sbindir, 'mkhomedir_helper')
|
2014-11-19 02:41:12 +00:00
|
|
|
pam_plugin_append_file('%spam-plugin-console' % mlprefix, pam_sbindir, 'pam_console_apply')
|
2012-07-11 17:33:43 +00:00
|
|
|
do_split_packages(d, pam_filterdir, '^(.*)$', 'pam-filter-%s', 'PAM filter for %s', extra_depends='')
|
2010-08-03 07:53:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
do_install() {
|
|
|
|
|
autotools_do_install
|
|
|
|
|
|
|
|
|
|
# don't install /var/run when populating rootfs. Do it through volatile
|
2012-08-05 19:48:47 +00:00
|
|
|
rm -rf ${D}${localstatedir}
|
2010-08-03 07:53:38 +00:00
|
|
|
install -d ${D}${sysconfdir}/default/volatiles
|
2012-08-05 19:48:47 +00:00
|
|
|
install -m 0644 ${WORKDIR}/99_pam ${D}${sysconfdir}/default/volatiles
|
2010-08-03 07:53:38 +00:00
|
|
|
|
2015-06-03 16:42:01 +00:00
|
|
|
install -d ${D}${sysconfdir}/pam.d/
|
2010-08-03 07:53:38 +00:00
|
|
|
install -m 0644 ${WORKDIR}/pam.d/* ${D}${sysconfdir}/pam.d/
|
2011-08-20 07:30:32 +00:00
|
|
|
|
2013-06-20 16:38:23 +00:00
|
|
|
# The lsb requires unix_chkpwd has setuid permission
|
|
|
|
|
chmod 4755 ${D}${sbindir}/unix_chkpwd
|
2013-09-19 15:03:21 +00:00
|
|
|
|
2014-04-24 18:59:20 +00:00
|
|
|
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
|
2013-09-19 15:03:21 +00:00
|
|
|
echo "session optional pam_systemd.so" >> ${D}${sysconfdir}/pam.d/common-session
|
|
|
|
|
fi
|
2011-08-20 07:30:32 +00:00
|
|
|
}
|
2013-06-20 16:38:24 +00:00
|
|
|
|
|
|
|
|
python do_pam_sanity () {
|
2014-04-24 18:59:20 +00:00
|
|
|
if not bb.utils.contains('DISTRO_FEATURES', 'pam', True, False, d):
|
2013-06-20 16:38:24 +00:00
|
|
|
bb.warn("Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly")
|
|
|
|
|
}
|
|
|
|
|
addtask pam_sanity before do_configure
|
2014-08-11 20:21:44 +00:00
|
|
|
|
|
|
|
|
BBCLASSEXTEND = "nativesdk native"
|
2014-11-21 09:17:13 +00:00
|
|
|
|
|
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/pam.d/common-session"
|
|
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/pam.d/common-auth"
|
|
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/pam.d/common-password"
|
|
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/pam.d/common-session-noninteractive"
|
|
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/pam.d/common-account"
|
2016-03-09 09:19:40 +00:00
|
|
|
CONFFILES_${PN}-runtime += "${sysconfdir}/security/limits.conf"
|
