Re: ITS#98 'user' patch for BSD systems

[patl@phoenix.volant.org]

> I would think it vary wise to model our setuid/gid/chroot handling
> after well established daemons.  As I noted before, bind seems to
> have clean implementation of this functionality that we could
> utilize as our model.
> 
> I would hestitate before adding some of the 'generalizations'
> discussed.  I think bind's handling of the the special cases is
> reasonable.

The only generalization that we're seriously discussing is the
ability to specify a list of groups explicitly rather than just
one.  I believe this is warranted by the need for slapd to be
able to access a variety of databases via different back-ends
which may have different group access requirements.

Yes, this could be handled by just specifying a user by name and
requiring that user to be in all of the required groups.  But
doing so separates the access settings from the rest of the config.

>      -u user_name
>                  Specifies the user the server should run as after it
>                  initial- izes.  The value specified may be either a
>                  username or a nu- meric user id.  If the ``-g'' flag is not
>                  specified, then the group id used will be the primary group
>                  of the user specified (initgroups() is called, so all of
>                  the user's groups will be available to the server).
> 
>      -g group_name
>                  Specifies the group the server should run as after it ini-
>                  tializes.  The value specified may be either a groupname
>                  or a numeric group id.

That sounds like what we are doing.  (Modulo the use of a config file
command instead of command-line options.)

> The only issue is if the user is specified by uid and no group is
> specified. However, in this case, initgroups calls setgroups(0, groups). 
> This clears the group vector for the process.  This seems reasonable to
> me.

Right.  We are suggesting doing a uid->name lookup to get the default
group access list for that user.  (If there is at least one passwd
entry for that uid.)  I don't think it's possible to have a process
with no group at all; so lookup failure should cause an abort.

> In particular, see:
>  
>  
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind/bin/named/ns_main.c?rev=1.1.1.2


Hmmmm.  I note that they do setgid()/setuid(); but don't seem to
explicitly invoke seteuid()/setegid().  I'm under the impression
that there are some non-POSIX environments where setuid() alone
isn't enough.  (But I could be wrong.)

I also notice that they are doing the initgroups() after the
chroot; so the group access lookup would be done in the chrooted
environment.  It's something to keep in mind when/if we add a
chroot option.



-Pat