From mboxrd@z Thu Jan 1 00:00:00 1970 From: martin f krafft Date: Mon, 20 Dec 2004 18:04:16 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: <20041220180416.GA29192@cirrus.madduck.net> MIME-Version: 1 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" List-Id: References: <20041217083115.GA4050@wonderland.linux.it> In-Reply-To: <20041217083115.GA4050@wonderland.linux.it> To: linux-hotplug@vger.kernel.org --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Lindsay Haisley [2004.12.20.1856 +0100]: > 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. Uh, are you arguing for or against permissions.d now? > 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 comm= on > 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. On all systems that I have, the only changes I made to the default udev ruleset were adjusting permissions. For all I care, rules.d could be in /usr/share and /etc/udev/rules.d could just as well be empty... if permissions.d is available. > 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. Is it? Is a discussion closed if some of the involved parties simply refuse to discuss for no reason other than "no, i will not consider this?" Making permissions.d optional would be okay, but then please make it take precedence. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "man soll nicht in kirchen gehn, wenn man reine luft atmen will." - friedrich nietzsche --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBxxQgIgvIgzMMSnURApS/AJ9OcEtMWKmms8rmyq8NFTOYQWueDgCgz5Nh 2G7lJaTsrGbu1gy3zMF0c9s= =kE65 -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- ------------------------------------------------------- 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