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]};