On 29-Jan-01 Louis A. Mamakos wrote:
>> 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"
People whine about the problem though, so having no solution doesn't
help either. Since #include is syntatically a comment, it shouldn't
mess up other programs, though the idea is that they will all use the
API in libc and not be reading the file themselves. However, I do
think that doing it through nsswitch might be the best solution.
> louie
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
