Re: [gentoo-embedded] emerge --root : users not created

[P. Levine]

On 02/23/2010 11:58 AM, Ned Ludd wrote:
> Q:
> If the end user is using Linux-Pam on his/her host system and they run
> this. It will ignore loading extra pam modules when entering the chroot?
> Or do they flat out need to disable pam on the host so they can take
> advantage of this for the chroot?

They don't need to disable pam for useradd, groupadd, etc... for the
same reason they don't for the chroot command.  PAM is for
authenticating users (attempting to ensure that a user who wants to use
a utility that he or she already has permission to, is indeed that
user).  Also keep in mind that all the chroot() function does is
(basically) prefix the path string in any functions (within the same
process or child processes) explicitly dealing with paths (fopen, for
example) with a sub path string (as if the process is changing the
directory to the chroot() path and then treating all absolute paths from
that point on as relative paths, and paths prefixed with "./" are
treated relative to the ACTUAL directory the process exists in , i.e.
the program was called from).

The chroot() function is privileged process with the  CAP_SYS_CHROOT
capability.  Even the chroot program which uses the chroot() function
doesn't check if you're root, if it should delegate such a capability on
a particular uid or call on PAM.  It assumes it is being run as root and
if chroot() fails it simply spits out "cannot change root directory to
...".  My patch at least checks if the uid is 0 and if not emits "must
be superuser for chroot access".

PAM processes are called by shadow (at least where I've encountered them
so far) to pre-authenticate a user (and only when both
--enable-account-tools-setuid and --with-libpam were enabled at
configure time) to use the particular utility.  That it would do so even
if the user was root seems to me a redundancy (since a system
would/should not allow root to grant or deny certain access rights
to/from itself).  When the program is called (suid bit enabled) PAM
takes care of the uid, euid discrepancy.  The chroot() process however,
shouldn't be called by a non-root user, period.  There are non-standard
modules on other systems to enable suid + chroot() + PAM authentication,
they are used to mimic the chroot utility (so a user can login to their
own subdirectory jail).  It seems to me it would be an unnecessary
security risk to allow a non-root user to authenticate to add/delete
users/groups from an offset directory.  This should be left to root
only.  Otherwise a dependency on pam_chroot or some other non-standard
module would have to be created, or a new module would have to be
written just for the --chroot option.

In short, using the --chroot option if compiled with --with-libpam is
fine so long as it's actually run as root.  As far as I know, emerge has
to be run as root (except for --pretend and searching).