Re: Bug#286040: please allow permissions.d to follow symlinks

[Greg KH <greg@kroah.com>]

On Fri, Dec 17, 2004 at 05:14:00PM +0100, martin f krafft wrote:
> 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.

I think Kay properly stated my argument already.  I'll leave it at that
for now, as he has done a wonderful job so far.

> 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.

Actually I was considering just dropping the permissions.d file
entirely, as I think we don't need it anymore.  But I have not had the
time to determine if this is possible or not just yet.

And you can name permissions.d whatever you want, udev puts no such
restrictions on the name of it.
the_udev_developers_are_wankers_and_dont_do_what_I_want.d, for example,
will work just fine too if you so desire.

> > 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.

What about the fun interaction with pam that causes device nodes to
"magically" assume other permissions.  Are you objecting to that too?

> 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...

I have yet to see a patch that offers such an "improvement" in this
thread.  If you ever create one, I would love to see it posted on the
list for everyone to evaluate.  Until then, this argument is over.

> 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.

Um, I have no control over the debian udev rules files, I just mirror in
the udev tree what the maintainer gives to me.

greg k-h


-------------------------------------------------------
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