Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 481704 - www-servers/lighttpd - tbz2 should set up user/group on target filesystem
Summary: www-servers/lighttpd - tbz2 should set up user/group on target filesystem
Status: RESOLVED DUPLICATE of bug 53269
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Alex Alexander (RETIRED)
Depends on:
Reported: 2013-08-19 23:09 UTC by Rafal Lalik
Modified: 2014-01-05 21:29 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Rafal Lalik 2013-08-19 23:09:02 UTC

When installing some service, like lighttpd, proper user and group are add to the shadow/passwd/groups files in /etc. In case of i.e. lighttpd it is done by calling fowners function in the ebuild.

But problem arises when target is cross-compiled. When adding new user/groups, portage functions are modifying /etc/{passwd,shadow,...} instead of ${SYSROOT}/etc/passwd. To verify whether the user/group exists the getent command is also used, which always is checking /etc/nsswitch.conf even if SYSROOT is set. Thus we are mixing configs for host and target.

Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2013-08-20 13:47:14 UTC
Maybe the lighttpd ebuilds should simply repeat these lines from pkg_setup() in pkg_preinst():

    enewgroup lighttpd
    enewuser lighttpd -1 -1 /var/www/localhost/htdocs lighttpd
Comment 2 Rafal Lalik 2013-08-20 14:11:51 UTC
No, it will not help - I have checked this.

IMHO problem lays in portage (that is why I refer bug to it). Please check /usr/portage/eclass/user.eclass. Inside you can find function enewuser which you have proposed to use.

Firstly, to check whether user exists tgetent is used, which is a wrapper for system getent, which then reads database from /etc.

Secondly, to add user it uses system commands like useradd which will touch /etc, not $SYSROOT/etc

Thus I would say this is general problem of portage, not of the ebuild.
Comment 3 Rafal Lalik 2013-08-23 10:52:57 UTC
Could I ask to restore original title - to bring more attention to this bug? As I explained before, I am rather convinced that bug is related to the portage, not to lighttpd.

Comment 4 Markos Chandras (RETIRED) gentoo-dev 2013-08-23 13:08:09 UTC
I am not 100% certain how to solve this so CC'ing portage
Comment 5 Zac Medico gentoo-dev 2013-08-23 18:41:22 UTC
(In reply to Rafal Lalik from comment #2)
> IMHO problem lays in portage (that is why I refer bug to it). Please check
> /usr/portage/eclass/user.eclass. Inside you can find function enewuser which
> you have proposed to use.

Yes it's bug 53269.
Comment 6 Rafal Lalik 2013-08-24 15:00:33 UTC
I think I found some solution, kind of work around.
Lets take an example of lighttpd:
- we need to add user to the system,
- set proper owners for /var/{lib.log}/lighttpd,
- our sysroot is in $SYSROOT (wherever it points).

Example of solution:

1) lets create temporary chroot environment, for example in SR=/tmp/sysroot:
mkdir $SR
mount --bind / $SR
mount --bind $sysroot/etc $SR/etc
mount --bind $sysroot/var/lib $SR/var/lib
mount --bind $sysroot/var/llog $SR/var/log

2) create user/group (all sys-apps/shadow apps support chrooting)
useradd --root $SR lighttpd

3) set owners:
/usr/bin/chroot $SR /bin/bash -c "chown -R lighttpd:lighttpd /var/{lib,log}/lighttpd

4) unmount all binds

Binding can be dangerous if proper dir structure doesn't exists on the $SR, but it could be avoided by for example, temporary bind locations in, i.e. $SR/tmp/bind{1,2,3,...}

Changes are mostly required is user.eclass

Maybe additional use of trap will be need to prevent leaving binds mounted after crash.

Another question is whether all architectures keeps passwd/shadow in the samo format, if using useradd of build machine will not corrupt files on SYSROOT machine.
Comment 7 Zac Medico gentoo-dev 2013-08-24 15:11:27 UTC
For chroot when cross-compiling for a different architecture, it could use binfmt_misc and qemu for emulation. It's kind of inefficient and ugly though. It's much nicer to take advantage of things like shadow's --root option which is mentioned in bug #53269, comment #49.
Comment 8 Rafal Lalik 2013-08-24 15:34:05 UTC
But this requires to use 3rd hand software whereas normal binding and chroot use what is already in the basic system. What more, you would need to identify architecture of sysroot system, etc. In my opinion qemu is to problematic. I also found this propositions on the web but refused it as usable.
Comment 9 SpanKY gentoo-dev 2014-01-05 21:29:31 UTC

*** This bug has been marked as a duplicate of bug 53269 ***