From mboxrd@z Thu Jan 1 00:00:00 1970 From: martin f krafft Date: Sat, 18 Dec 2004 04:21:11 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: <20041218042111.GA1962@cirrus.madduck.net> MIME-Version: 1 Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" List-Id: References: <20041217083115.GA4050@wonderland.linux.it> In-Reply-To: <20041217083115.GA4050@wonderland.linux.it> To: linux-hotplug@vger.kernel.org --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Greg KH [2004.12.18.0404 +0100]: > So, on what "technological level" do you rank the current crop of > distros (and by "crop" I mean ones that have had a release.)=20 I do not rank. Fact is that I will see whether Debian can continue to use permissions.d and provide the symlink following I initially requested, simply because I consider policy-based approaches to be important. Without going comparative, this is going to put Debian on a different level than other distros which go ahead to dump permissions.d *with respect to* udev permission handling. This will make it difficult to converge on a common set of rules. You told me at Sucon '04 that (one of) your main beef(s) with Debian is that we do not make patches with improvements available upstream. I promised you I would look into this and try to improve the situation. However, reading the archives, talking to Marco, and looking at bugs, it seems to me that we are banging our heads against the wall that you hold up, that you simply do not want our patches. A bystander might conclude from this very case we are discussing here that you are now crippling upstream just to make sure it will differ from Debian. Note that this is a bystander, I am not accusing you of this. You will probably have to agree that it could be interpreted as such. I embrace permissions.d because it is in the same spirit that a lot of things are done in Debian. Unless you give me technical reasons (read: plain facts) why permissions.d is just wrong, I might be inclined to support the bystander's opinion... Why is it wrong to manage device permissions in a central location, using a scheme that is intuitive to the user because it allows the user to specify the desired state rather than having to think a lot. flash:root:flash:0660 means: make the device available at /dev/flash readable only by root and members of flash. Whether /dev/flash translates to /dev/sda1 or /dev/your_mom or /dev/null... who cares? If a user specifies the above and makes herself a member of flash and then gets a permission denied error when trying to mount /dev/flash because she wanted /dev/flash to be readable, not /dev/whatever, then she will care. What is the benefit of merging permissions in with rules that identify and name devices? If you answered that, please also think about the reasons why Fedora uses /etc/sysconfig (and Gentoo probably does something similar). > And why wouldn't all distros benifit from such a set of unified rules? I am not at all denying this. How to unify rules when there are differences in opinions? --=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 "science without religion is lame, religion without science is blind." -- albert einstein --xHFwDpU9dbj6ez1V 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) iD8DBQFBw7A3IgvIgzMMSnURAqoaAJwJHiMzBP23MIAz9DhRm6x4vN9qiQCgh5F3 c/SjZrNZIMpbLzCMKeUr1vA= =Ut8z -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- ------------------------------------------------------- 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