Patchwork [2/7] shadow: add a -native recipe with customized utilities

login
register
mail settings
Submitter Phil Blundell
Date Sept. 1, 2011, 4:41 p.m.
Message ID <1314895291.19905.197.camel@phil-desktop>
Download mbox | patch
Permalink /patch/10871/
State New, archived
Headers show

Comments

Phil Blundell - Sept. 1, 2011, 4:41 p.m.
On Thu, 2011-09-01 at 15:46 +0100, Phil Blundell wrote:
> I just tried using useradd.bbclass for the first time (in an effort to
> make dbus installable on a readonly-rootfs) and it doesn't seem to be
> working very well for me.
> 
> The root of my problem seems to be the code below.  As far as I can
> tell, what's happening is that process_root_flag() consumes all the
> command line arguments to useradd, which means that the subsequent call
> to getopt() in process_flags() just returns immediately because there is
> nothing left for it to do.  The upshot of all this is that the switches
> on the command line are simply ignored and useradd doesn't do what I
> wanted.
> 
> Is anybody else using this code successfully in oe-core with a
> nontrivial USERADD_PARAM?

So, I added a strategic "optind = 1" to useradd.c and the situation
seems to have improved a bit.  However, I've encountered a couple of
other issues which are slightly annoying:

a) with the attached patch, dbus itself no longer requires a postinst to
be run at boot time.  Which is cool.  Unfortunately, inheriting useradd
causes it to now depend on shadow (which wasn't previously in my image)
and shadow itself isn't currently amenable to read-only-rootfs either so
my image build still fails.  I guess the answer to this is to have
shadow excluded (by some or other mechanism) during rootfs construction
for non-package-management-enabled images.

b) the useradd.bbclass stuff seems to try to apply itself to
virtclass-native packages as well, which was causing an error during
do_install() for dbus-native.  I worked around this by adding

USERADD_PARAM_${PN}_virtclass-native = ""
GROUPADD_PARAM_${PN}_virtclass-native = ""

to the recipe, but it seems as though the class should probably be
sorting this out for itself.

p.
Mark Hatle - Sept. 1, 2011, 4:54 p.m.
On 9/1/11 11:41 AM, Phil Blundell wrote:
> On Thu, 2011-09-01 at 15:46 +0100, Phil Blundell wrote:
>> I just tried using useradd.bbclass for the first time (in an effort to
>> make dbus installable on a readonly-rootfs) and it doesn't seem to be
>> working very well for me.
>>
>> The root of my problem seems to be the code below.  As far as I can
>> tell, what's happening is that process_root_flag() consumes all the
>> command line arguments to useradd, which means that the subsequent call
>> to getopt() in process_flags() just returns immediately because there is
>> nothing left for it to do.  The upshot of all this is that the switches
>> on the command line are simply ignored and useradd doesn't do what I
>> wanted.
>>
>> Is anybody else using this code successfully in oe-core with a
>> nontrivial USERADD_PARAM?
> 
> So, I added a strategic "optind = 1" to useradd.c and the situation
> seems to have improved a bit.  However, I've encountered a couple of
> other issues which are slightly annoying:
> 
> a) with the attached patch, dbus itself no longer requires a postinst to
> be run at boot time.  Which is cool.  Unfortunately, inheriting useradd
> causes it to now depend on shadow (which wasn't previously in my image)
> and shadow itself isn't currently amenable to read-only-rootfs either so
> my image build still fails.  I guess the answer to this is to have
> shadow excluded (by some or other mechanism) during rootfs construction
> for non-package-management-enabled images.

What is it depending on for the target?  Is the shadow-utils or something now
required?  That doesn't seem to make sense to me -- other then we need a
passwd/group/shadow/gshadow file to work with.  As long as something can provide
those, we should be ok.

> b) the useradd.bbclass stuff seems to try to apply itself to
> virtclass-native packages as well, which was causing an error during
> do_install() for dbus-native.  I worked around this by adding
> 
> USERADD_PARAM_${PN}_virtclass-native = ""
> GROUPADD_PARAM_${PN}_virtclass-native = ""

Yup, definitely a bug and should be fixed.  native and cross cases should not do
anything with useradd.

--Mark

> to the recipe, but it seems as though the class should probably be
> sorting this out for itself.
> 
> p.
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Sept. 1, 2011, 4:58 p.m.
On Thu, 2011-09-01 at 11:54 -0500, Mark Hatle wrote:
> What is it depending on for the target?  Is the shadow-utils or something now
> required?  That doesn't seem to make sense to me -- other then we need a
> passwd/group/shadow/gshadow file to work with.  As long as something can provide
> those, we should be ok.

I haven't investigated in detail, but the code from useradd.bbclass
says:

# base-passwd-cross provides the default passwd and group files in the
# target sysroot, and shadow -native and -sysroot provide the utilities
# and support files needed to add and modify user and group accounts
DEPENDS_append = " base-passwd shadow-native shadow-sysroot"
RDEPENDS_${USERADDPN}_append = " base-passwd shadow"

And, I guess, if you want to support online package management then it
does make some sense to have the shadow utils there.  But I don't
need/want that in my configuration.

p.
Mark Hatle - Sept. 1, 2011, 5:25 p.m.
On 9/1/11 11:58 AM, Phil Blundell wrote:
> On Thu, 2011-09-01 at 11:54 -0500, Mark Hatle wrote:
>> What is it depending on for the target?  Is the shadow-utils or something now
>> required?  That doesn't seem to make sense to me -- other then we need a
>> passwd/group/shadow/gshadow file to work with.  As long as something can provide
>> those, we should be ok.
> 
> I haven't investigated in detail, but the code from useradd.bbclass
> says:
> 
> # base-passwd-cross provides the default passwd and group files in the
> # target sysroot, and shadow -native and -sysroot provide the utilities
> # and support files needed to add and modify user and group accounts
> DEPENDS_append = " base-passwd shadow-native shadow-sysroot"
> RDEPENDS_${USERADDPN}_append = " base-passwd shadow"

Hmm, good point... I'd forgotten about that.

> And, I guess, if you want to support online package management then it
> does make some sense to have the shadow utils there.  But I don't
> need/want that in my configuration.

Does busybox or something else provide a compatible adduser?  If so maybe a
virtual RDEPENDS is more reasonable in this case.

I think we're caught in the case of we build packages.. as such we need to cover
what the package needs at runtime, this includes install time.  At least w/ a
virtual depend, we can likely fake it by providing it by something else.. but
I'm not sure..

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Sept. 1, 2011, 7:44 p.m.
On Thu, 2011-09-01 at 12:25 -0500, Mark Hatle wrote:
> On 9/1/11 11:58 AM, Phil Blundell wrote:
> > And, I guess, if you want to support online package management then it
> > does make some sense to have the shadow utils there.  But I don't
> > need/want that in my configuration.
> 
> Does busybox or something else provide a compatible adduser?  If so maybe a
> virtual RDEPENDS is more reasonable in this case.

I'm not sure offhand (it's actually useradd, not adduser, for what
that's worth) but, even if busybox does provide those applets, that
probably isn't quite the point.  The issue here is that I don't really
want to have any implementation of useradd at all on the target system;
using one from busybox would be a bit less bad than requiring standalone
shadow, but still not really ideal.

One workaround would be to weaken the RDEPENDS to an RRECOMMENDS, which
would allow me to declare it as a BAD_RECOMMENDATION.  Or I guess we
could make it be a virtual and I could then provide a dummy-useradd
package which satisfies the dependency but doesn't actually install any
files.  

The approach we take with update-rc.d is to let it be installed and then
have rootfs_ipk rip it back out again after image construction is done,
but this won't work with shadow as it stands due to the postinst issue
in that package.  So a third option would be to find a way to finesse
the postinst thing somehow and then use the same rootfs_ipk logic with
shadow too.

None of those really sound very appealing.  Anybody have a better idea?

p.
Richard Purdie - Sept. 1, 2011, 9:59 p.m.
On Thu, 2011-09-01 at 20:44 +0100, Phil Blundell wrote:
> On Thu, 2011-09-01 at 12:25 -0500, Mark Hatle wrote:
> > On 9/1/11 11:58 AM, Phil Blundell wrote:
> > > And, I guess, if you want to support online package management then it
> > > does make some sense to have the shadow utils there.  But I don't
> > > need/want that in my configuration.
> > 
> > Does busybox or something else provide a compatible adduser?  If so maybe a
> > virtual RDEPENDS is more reasonable in this case.
> 
> I'm not sure offhand (it's actually useradd, not adduser, for what
> that's worth) but, even if busybox does provide those applets, that
> probably isn't quite the point.  The issue here is that I don't really
> want to have any implementation of useradd at all on the target system;
> using one from busybox would be a bit less bad than requiring standalone
> shadow, but still not really ideal.
> 
> One workaround would be to weaken the RDEPENDS to an RRECOMMENDS, which
> would allow me to declare it as a BAD_RECOMMENDATION.  Or I guess we
> could make it be a virtual and I could then provide a dummy-useradd
> package which satisfies the dependency but doesn't actually install any
> files.  
> 
> The approach we take with update-rc.d is to let it be installed and then
> have rootfs_ipk rip it back out again after image construction is done,
> but this won't work with shadow as it stands due to the postinst issue
> in that package.  So a third option would be to find a way to finesse
> the postinst thing somehow and then use the same rootfs_ipk logic with
> shadow too.

The latter sounds like what we'll need to do. I haven't looked at shadow
to see what kind of finessing is required though...

Does opkg have any notion of bitbake's ASSUME_PROVIDED?

Cheers,

Richard
Mark Hatle - Sept. 2, 2011, 12:02 a.m.
On 9/1/11 4:59 PM, Richard Purdie wrote:
> On Thu, 2011-09-01 at 20:44 +0100, Phil Blundell wrote:
>> On Thu, 2011-09-01 at 12:25 -0500, Mark Hatle wrote:
>>> On 9/1/11 11:58 AM, Phil Blundell wrote:
>>>> And, I guess, if you want to support online package management then it
>>>> does make some sense to have the shadow utils there.  But I don't
>>>> need/want that in my configuration.
>>>
>>> Does busybox or something else provide a compatible adduser?  If so maybe a
>>> virtual RDEPENDS is more reasonable in this case.
>>
>> I'm not sure offhand (it's actually useradd, not adduser, for what
>> that's worth) but, even if busybox does provide those applets, that
>> probably isn't quite the point.  The issue here is that I don't really
>> want to have any implementation of useradd at all on the target system;
>> using one from busybox would be a bit less bad than requiring standalone
>> shadow, but still not really ideal.
>>
>> One workaround would be to weaken the RDEPENDS to an RRECOMMENDS, which
>> would allow me to declare it as a BAD_RECOMMENDATION.  Or I guess we
>> could make it be a virtual and I could then provide a dummy-useradd
>> package which satisfies the dependency but doesn't actually install any
>> files.  
>>
>> The approach we take with update-rc.d is to let it be installed and then
>> have rootfs_ipk rip it back out again after image construction is done,
>> but this won't work with shadow as it stands due to the postinst issue
>> in that package.  So a third option would be to find a way to finesse
>> the postinst thing somehow and then use the same rootfs_ipk logic with
>> shadow too.
> 
> The latter sounds like what we'll need to do. I haven't looked at shadow
> to see what kind of finessing is required though...
> 
> Does opkg have any notion of bitbake's ASSUME_PROVIDED?

RPM has a mechanism to provide a list of "provided" items.  But there is not
currently any logic to seed that data.  If there is a standard list, it's
something we can add easily enough.

--Mark

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Sept. 2, 2011, 7:15 a.m.
On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> The latter sounds like what we'll need to do. I haven't looked at shadow
> to see what kind of finessing is required though...
> 
> Does opkg have any notion of bitbake's ASSUME_PROVIDED?

Not explicitly, but the same mechanism that we use for
BAD_RECOMMENDATIONS could be bent to do it; that wouldn't be very
hard.  

OTOH, I don't think this would buy much compared to just removing it
after installation (as we do with base-passwd already) so I'm not sure
that any extra mechanics are justified.  We'd have to address the
postinst issue either way around, so that's probably the thing to look
at first.

p.

Patch

diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index a8ecda8..7010002 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -14,11 +14,21 @@  SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
            file://tmpdir.patch; \
            file://dbus-1.init"
 
-inherit autotools pkgconfig gettext update-rc.d
+inherit autotools pkgconfig gettext update-rc.d useradd
+
+USERADD_PACKAGES = "${PN}"
+USERADD_PARAM_${PN} = "-d ${MESSAGEHOME} -g ${MESSAGEUSER} -r -N ${MESSAGEUSER}"
+GROUPADD_PARAM_${PN} = "${MESSAGEUSER}; netdev"
+USERADD_PARAM_${PN}_virtclass-native = ""
+GROUPADD_PARAM_${PN}_virtclass-native = ""
 
 INITSCRIPT_NAME = "dbus-1"
 INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
 
+MESSAGEUSER=messagebus
+MESSAGEHOME="${localstatedir}/run/dbus"
+UUIDDIR="${localstatedir}/lib/dbus"
+
 CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf"
 
 DEBIANNAME_${PN} = "dbus-1"
@@ -38,38 +48,22 @@  FILES_${PN} = "${bindir}/dbus-daemon* \
                ${libexecdir}/dbus* \
                ${sysconfdir} \
                ${datadir}/dbus-1/services \
-               ${datadir}/dbus-1/system-services"
+               ${datadir}/dbus-1/system-services \
+	       ${MESSAGEHOME} \
+	       ${UUIDDIR}"
 FILES_${PN}-lib = "${libdir}/lib*.so.*"
 RRECOMMENDS_${PN}-lib = "${PN}"
 FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
 
-pkg_postinst_dbus() {
-	# can't do adduser stuff offline
-	if [ "x$D" != "x" ]; then
-		exit 1
-	fi
-
-	MESSAGEUSER=messagebus
-	MESSAGEHOME=/var/run/dbus
-	UUIDDIR=/var/lib/dbus
-
-	mkdir -p $MESSAGEHOME
-	mkdir -p $UUIDDIR
-	chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER"
-	chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \
-		adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \
-			--ingroup "$MESSAGEUSER" "$MESSAGEUSER"
+pkg_postinst_${PN}() {
+	chgrp "${MESSAGEUSER}" "${MESSAGEHOME}"
+	chown "${MESSAGEUSER}":"${MESSAGEUSER}" "${MESSAGEHOME}"
+	chown "${MESSAGEUSER}":"${MESSAGEUSER}" "${UUIDDIR}"
 
-	chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR"
+	chown root:"${MESSAGEUSER}" $D${libexecdir}/dbus-daemon-launch-helper
+	chmod 4754 $D${libexecdir}/dbus-daemon-launch-helper
 
-	grep -q netdev: /etc/group || addgroup netdev
-
-	chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper
-	chmod 4754 /usr/libexec/dbus-daemon-launch-helper
-
-	# add volatile after new user/grp are created
-	echo "d messagebus messagebus 0755 /var/run/dbus none" > /etc/default/volatiles/99_dbus
-	if [ -e /etc/init.d/populate-volatile.sh ] ; then
+	if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
 		/etc/init.d/populate-volatile.sh update
 	fi
 }
@@ -95,6 +89,12 @@  do_install() {
 	# disable dbus-1 sysv script on systemd installs
 	# nearly all distros call the initscript plain 'dbus', but OE-core is different
 	ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
+
+	install -d ${D}${UUIDDIR}
+	install -d ${D}${MESSAGEHOME}
+
+	install -d ${D}${sysconfdir}/default/volatiles
+	echo "d messagebus messagebus 0755 /var/run/dbus none" > ${D}${sysconfdir}/default/volatiles/99_dbus
 }
 
 do_install_virtclass-native() {