From: martin f krafft <madduck@madduck.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Bug#286040: please allow permissions.d to follow symlinks
Date: Fri, 17 Dec 2004 16:14:00 +0000 [thread overview]
Message-ID: <20041217161400.GA506@cirrus.madduck.net> (raw)
In-Reply-To: <20041217083115.GA4050@wonderland.linux.it>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
also sprach Greg KH <greg@kroah.com> [2004.12.17.1650 +0100]:
> Sorry, but Kay is correct. udev isn't going to be changed to
> modify the permissions of the target of the symlink.
If that is the decision, so be it. I would be interested in hearing
proper arguments why this is not done. You heard ours... using
a symlink is preferable over renaming the device node, and expecting
rules to do what permissions.d could potentially do instead is
backwards. Moreover, it means that permission management now happens
outside of permissions.d too. Maybe you should then rename
permissions.d to node-permissions.d ? The administrator, in the end,
does not care at all whether an inode is a device node or a symlink
pointing to a device node.
> udev has the capability to properly change the permissions based
> on a rule or a external program.
I thought udev is all about policy. What's the point about a policy
if it does not impose a strict syntax? A proper syntax (bad word
choice, I know) would define that permissions are to be changed
under permissions.d and nowhere else. Otherwise, the administrator
may be clueless when a device node "magically" assumes permissions,
but permissions.d does not contain an appropriate entry. This is one
of the core strengths in Debian and why I am here today to discuss.
Anyway, if you are not going to change it, maybe we will change it
in Debian. Then please do not complain again that we apparently do
not feed improvements upstream. We try...
Also, please remove permission entries like cdrom etc. from the
udev.permissions file. These make no sense there, since cdrom etc.
are symlinks in the default configurations.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
$complex->{'data'}[$structures][$in_perl] = @{$can{'be'}->[$painful]};
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-12-17 16:14 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-17 8:31 Bug#286040: please allow permissions.d to follow symlinks Marco d'Itri
2004-12-17 10:11 ` Stefan Schweizer
2004-12-17 10:48 ` martin f krafft
2004-12-17 13:24 ` Kay Sievers
2004-12-17 13:38 ` martin f krafft
2004-12-17 13:40 ` Marco d'Itri
2004-12-17 13:45 ` Kay Sievers
2004-12-17 13:47 ` Kay Sievers
2004-12-17 13:49 ` Marco d'Itri
2004-12-17 13:56 ` Kay Sievers
2004-12-17 13:58 ` martin f krafft
2004-12-17 14:13 ` Kay Sievers
2004-12-17 14:19 ` martin f krafft
2004-12-17 14:20 ` Kay Sievers
2004-12-17 14:35 ` martin f krafft
2004-12-17 14:36 ` Stefan Schweizer
2004-12-17 14:42 ` martin f krafft
2004-12-17 14:45 ` Kay Sievers
2004-12-17 14:52 ` martin f krafft
2004-12-17 15:50 ` Greg KH
2004-12-17 16:14 ` martin f krafft [this message]
2004-12-17 16:45 ` Greg KH
2004-12-17 17:10 ` martin f krafft
2004-12-17 17:45 ` Stefan Schweizer
2004-12-17 18:33 ` Greg KH
2004-12-17 18:40 ` martin f krafft
2004-12-17 23:25 ` Kay Sievers
2004-12-17 23:41 ` martin f krafft
2004-12-18 0:25 ` Lindsay Haisley
2004-12-18 0:53 ` martin f krafft
2004-12-18 1:18 ` martin f krafft
2004-12-18 3:04 ` Greg KH
2004-12-18 4:18 ` Lindsay Haisley
2004-12-18 4:21 ` martin f krafft
2004-12-18 9:48 ` Stefan Schweizer
2004-12-18 12:33 ` Tobias Klauser
2004-12-18 13:04 ` Marco d'Itri
2004-12-19 4:34 ` Randy.Dunlap
2004-12-20 9:39 ` martin f krafft
2004-12-20 17:56 ` Lindsay Haisley
2004-12-20 18:04 ` martin f krafft
2004-12-20 19:05 ` Lindsay Haisley
2004-12-21 8:04 ` martin f krafft
2004-12-21 16:11 ` Lindsay Haisley
2004-12-21 16:31 ` Lindsay Haisley
2004-12-21 16:38 ` martin f krafft
2004-12-21 16:48 ` Tobias Klauser
2004-12-21 16:54 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041217161400.GA506@cirrus.madduck.net \
--to=madduck@madduck.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).