Re: [Ltsp-developer] libpam-sshauth and libnss-sshsock

[Scott B. <sba...@le...>]

On Mon, Nov 14, 2011 at 10:56:37AM -0500, Gideon Romm wrote:
> >
> > I think Gadi's idea was to start using the nss_sshsock library right away,
> > to simplify some of the localapps code.  We'll need to test this fairly
> > thoughoghly to make sure there aren't any race conditions in the nss code.
> >
> 
> Localapps and fat clients are definitely the target for this type of
> module for LTSP. There is one "feature" of our current mangling code
> that we would have to find a better way of doing with this new nss
> module. That is, namely, system group memberships.
> 
> Ubuntu uses system group memberships to govern lots of permissions.
> When we wrote our mangling code, we asked such questions as, "What if
> the xyz system group in the chroot has a different gid than the xyz
> system group on the server?" A very possible problem, as many packages
> simply create a system group with the "next available gid" at the time
> of install.  So, we basically loop through all the group names and add
> the *server users* who are members of *server system groups* to the
> *client system groups* with the same *names*. Ugly, yes, but
> desirable.
> 
> Now, I figure there are a few options available to us to address this.
> Either we could:
> 
> 1. Introduce similar code (maybe activated by a flag of some sort) to
> do the same thing in our nss module. That is, the nss module could
> mange the gid's of the *server system group* to match those of the
> *client system group* and return those groups with the *server system
> group membership*.

Urk.  Couple of problems with that.  At the moment, nss_sshsock isn't
handling any uid's or gid's < MINUID & MINGID (in the .h file) for
specifically this reason.  The problem is, if you have it handle
the systems groups it:

1) has to be first in the module order and
2) won't have "proper" access to the local groups file.

Normally, in POSIX, if you want to look at the groups file,
you use getgrent() and related functions.  Of course, we can't
call getgrent() since WE'RE having to munge the group file, and
that would just end up in a recursive call.  So, we'll have to
manually re-implement group parsing code which is... ugly, and
fraught with problems.

> 2. We could use a different pam module, like pam_group that
> automatically adds users as members to system groups, and simply
> modify that module's configuration (even via lts.conf).

This, to my mind, seems to be a cleaner solution.  Since we're
going to want to use the pam_exec module anyway, part of the
scripting could be updating the /etc/security/group.conf file,
before the pam_group module's loaded.

We might not even need to do that...  Couldn't we just have static
entries adding everyone to the groups we need... sound, plugdev, fuse
etc. ?  Seems like we could just do that at chroot build time.

I could be missing something...

Scott