From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lindsay Haisley Date: Mon, 20 Dec 2004 17:56:11 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: <20041220175611.GC25934@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 Mon, Dec 20, 2004 at 03:39:50AM CST > Answering multiple mails in one... scroll down... > > > > also sprach Lindsay Haisley [2004.12.18.0518 +0100]: > > I really don't give a rip about "policy-based approaches". > > I hope for your sake that you will never have more users, or that > you have plenty of time available to make sure that you keep the > system running consistently and securly. Thanks for your concern, Martin ;-) I actually appreciate sensible policy design, and use and recommend Debian to people because, among other things, it's very solid in this regard. My point, which perhaps I made overly blunt, is that it's very easy from a developer's point of view to get away from the needs of real-life in-the-trenches system administration. I've seen this happen too often in otherwise excellent FOSS projects. > > 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. > > What is not logical about a line > > flash:root:flash:0660 > > in permissions.d? If you would not know about what permissions.d is, > what could you induce from > > - the directory name > - the syntax > - the name "flash" > - the actual stat() data? This point is well made, but pretty much the same could be said about a rules file. The question that comes to my mind is, what is the most common reason that anyone would want to change the device data structure in the first place. Generally, in my experience, it's because a new device has been added to the system. The first place one will probably want to go is to an appropriate udev rules file to set up something sensible in /dev for the new device, and for this, one-stop shopping is a plus. I would guess that adjusting owner/permissions on existing device nodes is a secondary task. > > I see no problem with having owner, group and mode spec'd in udev rules > > files. > > I wasn't saying it's a problem. Just that it's better and easier to > administer if you separate naming and permissions. We run a couple > system with separate sysadmins and policy people. It's *much* easier > to be able to give the first group write-access to the rules and the > second group access to the permissions. There are two problems. The first is that, in the current udev implementation, OWNER, GROUP, MODE in a rules file override settings in permissions.d. The second is the issue of following symlinks, which has been discussed at length. There should be no need to run ls -l on /dev to find out if a device node is a symlink or not, but that discussion is closed, I believe. > > Certainly this furthers the the purpose of centralization. > > uh, and centralisation is what we should all strive for blindly, > right? Well the best of all possible worlds would be to make the use of permissions.d optional. Ideal design would be such that commenting out udev_permissions in udev.conf would take it out of the config logic, but putting it in would cause udev to use it. The simpler, stricter syntax of permissions.d files make them much easier to manage via scripting in higher level tools. This would make everyone happy, but given the issues already raised, taking it out of the mix altogether may be the wisest choice. > > 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. > > Care to elaborate? See above :-) Thanks to all, and season's greetings! -- 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