From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lindsay Haisley Date: Sat, 18 Dec 2004 04:18:24 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: <20041218041824.GE4948@fmp.com> List-Id: References: <20041217083115.GA4050@wonderland.linux.it> In-Reply-To: <20041217083115.GA4050@wonderland.linux.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Thus spake martin f krafft on Fri, Dec 17, 2004 at 06:53:58PM CST > also sprach Lindsay Haisley [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://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