[Date Prev][Date Next]
Re: ITS#98 'user' patch for BSD systems
> > 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.
If it can be handled through normal system administration proceedures,
why do we need or want to add in behavior which runs counter to the
normal mechanism for specify groups for a user?
Allowing per backend additions to the group list would be counter intuitive.
I beleive the user and group configuration options be required before
any backend specification. It should be an fatal error to have multiple
"user" or multiple "group" directives.
> > -u user_name
> > -g group_name
> 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.
I would use initgroups() if available. If not available, I'd give up
on being able to call setgroups() (as they generally appeared together).
I'd just grab the primary gid from the password entry and do a setgid().
I'd get try getting the passwd entry first using getpwnam() and/or getpwuid().
If no password entry was available for the uid, exit.
> 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.
This is very common behavior of chroot'ing applications. I would
recommend chroot'ing BEFORE reading the configuration files. I
also recommend changing uid/gid before reading the configuration