> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
> > Hi,
> >
> > Asbestos suit on, round two.
> >
> > The patch below changes getusershell to support a #include syntax
> > in /etc/shells.
>
> I guess this is what I object to. I don't particularly like having a
> new directive in a configuration file which lots of applications read
> directly.
>
> I would rather that a separate configuration file be read, for example,
> with a list of shells(5) format files to consult.
>
> In current, this could be an optional thing, activated in nsswitch.conf,
> e.g. make a ports source for shells, and activate it with:
> shells: files ports
>
> or whatever you would like to call the source.
Does this capability really need to exist (e.g., supporting many files)? It
would seem like the additional complexity would be not what you want for what's
essentially a security policy mechansim. Who gets to own these included files?
What should their permissions be allowed to be?
It doesn't seem unreasonable to have a single file with a list of allowable
shells.
Is this #include capability going to be added for other files that ports
modify such as /etc/master.passwd and /etc/group?
I dunno; maybe it's just me, but this really seems like a solution way out
of proportion to the "problem"
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
