On 02/16/2010 10:04 AM, P. Levine wrote:
> Peter Stuge wrote:
>> I talked to upstream on freenode/#shadow and they welcome a patch for
>> adding --chroot
>>
>> chroot() needs to happen really early since useradd and friends read
>> some configuration files to know e.g. which password encryption
>> method to use.
> 
> Attached is a tentative patch to add a chroot flag to useradd and
> groupadd (via --chroot or -R).  It compiles and works on my end
> (--chroot /usr/armv4tl-softfloat-linux-gnueabi) with various other flags
> enabled.  I'm hoping for others to test it and get some feedback before
> I submit it to shadow upstream.
> 
> There do exist a couple of issues:
> 
> sysconf(_SC_NGROUPS_MAX) is called by useradd early on.  This would
> report the maximum allowable number of groups per user on the build
> system, not the target.  To my knowledge, this is set by the kernel and
> would have to be used.  However, this tends to be a very high number for
> linux kernel >= 2.6.3 (65536) so it seems like a mute point (for linux
> kernel >= 2.6.3).
> 
> There are a number of calls to "getXXbyYY" functions (i.e., getgrgid,
> getpwnam, etc...).  These seem to be dynamically preloaded and access
> preloaded databases.  They are unaffected by chroot() (even after
> setting __nss_configure_lookup(foo, files)).  I've instead used shadow's
> own method of macro expansion to generate functions doing the
> equivalent, with recursive calls to fgetXXent functions.
> 
> And PAM functionality doesn't work and has to be disabled while using
> chroot().  I don't know very much about PAM.  Would this be a problem?
> 
> Also,  the chroot functionality could probably be easily extended to
> other modules but I'm not sure if this would be acceptable upstream.
> 
> There are a couple of cosmetic changes I'm considering as well (such as
> how --chroot flag is parsed).
> 
> -- Peter Levine

Sorry, wrong patch.

I've attached the correct one.

-- Peter Levine