Pam modules.
From BononWiki
News
. 6 September 2011
Idea to write a pammodule using pam_exec, pam_chroot and pam_namespace, to create a chrooted namespace. First it runs some script, then creates a new namespace using the clone syscall, and then a chroot.
Ideas from nspawn from systemd, pam_chroot.so, pam_exec.so, pam_namespace.so and pam_script.so.
. 1 August 2011
Rewitten the pam_script.so module and published on Gitorious.
Changes
For details about recent changes see:
Examples
Combination with pam_chroot.so
In my setup I'm using pam_script.so to run scripts, in combination with pam_chroot.so. The scripts run by pam_script.so are creating the environment to chroot to, like remounting of the important system directories like:
mount --bind /bin /var/lib/workspace/%USER%/chroot/bin mount --bind /dev /var/lib/workspace/%USER%/chroot/dev .... etcetera ....
Not for every user/configuration this chroot is used. This depends on per user configuration. If the chroot is chosen, apart from the bind mounting, the user is made member of some groups, to make the pam_chroot.so do an actual chroot. If the chroot doesn't have to be performed, the user is deleted from those groups.
The pamfile for kde (kdm) looks like this:
session include system-auth session required pam_mkhomedir.so skel=/etc/skel umask=0022 session required pam_script.so runas=root expose=cookie initgroups session [default=1 success=ignore] pam_succeed_if.so user ingroup pamchroot session required pam_chroot.so use_ext_regex use_groups notfound=success onerr=succeed
First the module(s) in system-auth. They will set the env. parameter XDG_SESSION_COOKIE. On my machine the pammodule pam_systemd.so does that, formerly pam_ck_connector did the same.
I'm making use of the module pam_succeed_if.so, which can skip other modules based upon some rules, like is a user member of a group. Here the user has to be member of the group pamchroot to make use of the chroot module in the first place.
If that's the case pam_chroot.so will do it's job. It looks at /etc/security/chroot.conf to determine the directory to chroot to. In my case this file looks like:
# /etc/security/chroot.conf # basic format: # username chroot_dir @mount-md5key /var/lib/workspace/%u/chroot
which means that if the user USER is member of the group mount-md5key, a chroot is done to:
/var/lib/workspace/$USER/chroot
The configuration parameters in the pam service file tell the module to use groups, and when the directory to chroot to is not found, is just continues without error.
Namespaces
Using a file namespace is better than a chroot, I'm currently looking how to implement that. It looks like the special pam module pam_namespace.so is not able to cooperate with pam_chroot. Maybe a will write a pam module myself which does a chroot and creates a private namespace.
