[Date Prev][Date Next]
Re: breaking up slap_init_user() for better chroot functionality
One aspect you might be missing is that slapd(8) is often
used to provide the system user and group databases. This
is one of the reasons why we use separate user and group
However, as I noted before, the discussion of wether to
use a separate user/group database or not is moot. The
current code works as intended, people rely on it to
work that way, and so we're not going to change that
That said, I think that the code could be changed such
that when uid/gid where specified (and with support for
a list of gids), that we should not fail if the
user/password databases are unavailable. That is,
my id(1) suggestion should be made to work even where
user/password databases are unavailable.
At 11:20 AM 10/13/2004, Daniel Ott wrote:
>Howard Chu wrote:
>>Kurt D. Zeilenga wrote:
>>>At 07:58 AM 10/12/2004, Daniel Ott wrote:
>>>>Why do you think the suggested split would change command line semantics?
>>>Because the modifications would change the password
>>To expand on this - it is standard practice to use a customized password database inside a chroot'd environment, not the "real" system database. Altering the behavior here would prevent the use of such a customized database.
>I can see why you'd want to have a separate password database if you're trying to chroot-jail several daemons or remote logins but as far as running a single daemon chroot'd I can't say I'm convinced. I've looked at a few other deamons and found that most do the db lookups before the chroot. ISC's named even has this comment in the source:
> isc_result_t result;
> * Get the user and group information before changing the root
> * directory, so the administrator does not need to keep a copy
> * of the user and group databases in the chroot'ed environment.
>It seems to me that daemons that do the lookups after the chroot avoid this discussion because there is alot going on related to users after the chroot. ftp sessions... mail deliveries in some mail servers... and that's probably the case here with the shell, perl and passwd backends.
>Anyway, I won't harp on it anymore. Thanks for the discussion, adding clarification to the man page and all your work on the project as a whole.