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).
