[Date Prev][Date Next]
Re: ITS#98 'user' patch for BSD systems
> 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
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
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:
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