[Date Prev][Date Next]
Re: ITS#98 'user' patch for BSD systems
> > If no password entry was available for the uid, exit.
> Wow. For security, or for simplicity? If the latter, it's easy enough
> to be nicer: If uid _and_ a group is specified, we can do setuid,
> setgid, and like you mentioned setgroups(0, groups). But exit if uid
> was given but no group.
I meant that to be taken in the context where no groups are specified.
I.e., Iff the user is specified as a uid, and no groups are specified
at all, and there is no password entry for that uid, then issue a fatal
error. Because under those conditions we have no way to determine what
a reasonable or desirable group setting would be.
> > I would recommend chroot'ing BEFORE reading the configuration files.
> If it's done that early, couldn't the sysadmin just as well
> use the chroot shell command?
Another good point.
> > I also recommend changing uid/gid before reading the configuration
> > file.
> Then the startup sequence must be rearranged quite a bit. The most
> user-visible change might be that the pid file (which is specified by
> the config file) must then be written _after_ the bind(). That would be
> a pity; the file should exist as early as possible.
I'd forgotten about the pid and args files. More good reasons for
maintaining the current scheme where the config file is read before
the uid/gid change.
> I think it would be better to bite the bullet and follow Pat's
> suggestion to split read_config(): Parse the config file early, obey
> it later. Which means the config info must be remembered somewhere.
Actually, when I made that suggestion, I was under the impression that
the databases were opened and back-ends spawned as they were defined
instead of on-demand later. I think the current scheme still fits our