Re: Bug#286040: please allow permissions.d to follow symlinks

[Lindsay Haisley <fmouse-gentoo@fmp.com>]

Thus spake martin f krafft on Fri, Dec 17, 2004 at 06:53:58PM CST
> also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.18.0125 +0100]:
> > IMHO, designing in accord with the KISS principle is seldom an
> > evolutionary step backwards.
> 
> I agree that no permissions.d is better than not allowing nodes
> identified by symlinks to be changed.
> 
> However, I also think that having a central place to configure
> device permissions is favourable. Without udev, I can do that in
> /dev. With udev, I will now have to scan all rules, possibly dive
> into scripts and essentially pretend I am a shell script processor
> to figure out which permissions are actually being applied.
> 
> If you come from the system administration background, I wonder how
> you see a benefit in this approach! Are you aware of what
> policy-based approaches are, what they try to solve, and why they
> are a great idea, in programming, security management, or system
> administration?

I do not come from a "systems administration background".  I am an educated
human being who makes his living from providing Internet services that
others want and need, and have had to learn what I need to know to make it
happen.  I really don't give a rip about "policy-based approaches".  What I
_can_ tell you, is that when I encounter a new technology that I need to
use, I approach it in a pretty logical fashion, and expect the
implementation and documentation for it to be free of needless redundancies.
I expect the documentation to readily available, logically presented, and to
use defined terms and referenced concepts to provide a clear and useful path
into the facility it documents.  

I respect the capabilities of the developers who have put a great deal of
their time, effort, and above all their commitment to excellence into the
design of systems such as udev, and, while I may make suggestions from time
to time, I do not in any way presume to pass judgement on their efforts.

> Why do you think Debian has /etc/default and Fedora uses
> /etc/sysconfig (to give just two very trivial examples -- I am
> sorry, I am unaware of how Gentoo does things, but I assume them to
> be similar)?

Gentoo uses similar structures - several of them.

> We are not getting rid of these because they fulfill
> a very specific purpose: centralise configurable aspects of the
> System V init process. The performance impact they produce is
> negligible given how they facilitate administration.

I see no problem with having owner, group and mode spec'd in udev rules
files. Certainly this furthers the the purpose of centralization.  The
syntax of the file is reasonably forgiving, and anyone wanting a greater
degree of order could format it to personal taste so as to make it more
readable.
 
> When I saw permissions.d, I was rather impressed by its elegance
> (very reminiscent of how Debian does many things, actually -- yes,
> I am biased ;^>). How sad to have the developers turn around and
> stick their heads in the sand for no real reason.

Like you, I was reasonably impressed with the elegance and usefulness of the
facility in /etc/udev/permissions.d, however I also see problems with it.  I
happen to agree with the position that spec'd permissions should pass thru
symlinks to the linked devices.  An admin who needs to set device
permissions should be able to do so quickly and simply without reference to
other resources to tell him whether said devices are symlinks or not.  I
also don't particularly care for design redundancy, and furthermore,
although permissions.d is useful, it's overridden by values spec'd in udev
rules files, which begins to get confusing.  Things could be simpler, and it
looks as if Greg, Kay & others are on the right track.
 
-- 
Lindsay Haisley       | "Fighting against human |     PGP public key
FMP Computer Services |    creativity is like   |      available at
512-259-1190          |    trying to eradicate  | <http://pubkeys.fmp.com>
http://www.fmp.com    |        dandelions"      |
                      |      (Pamela Jones)     |


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel