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

[Lindsay Haisley <fmouse-gentoo@fmp.com>]

Thus spake martin f krafft on Mon, Dec 20, 2004 at 03:39:50AM CST
> Answering multiple mails in one... scroll down...
> 
> 
> 
> also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.18.0518 +0100]:
> > I really don't give a rip about "policy-based approaches".
> 
> I hope for your sake that you will never have more users, or that
> you have plenty of time available to make sure that you keep the
> system running consistently and securly.

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.

> > What I _can_ tell you, is that when I encounter a new technology
> > that I need to use, I approach it in a pretty logical fashion, and
> > expect the implementation and documentation for it to be free of
> > needless redundancies.
> 
> What is not logical about a line
> 
>   flash:root:flash:0660
> 
> in permissions.d? If you would not know about what permissions.d is,
> what could you induce from
> 
>   - the directory name
>   - the syntax
>   - the name "flash"
>   - the actual stat() data?

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

> > I see no problem with having owner, group and mode spec'd in udev rules
> > files.
> 
> I wasn't saying it's a problem. Just that it's better and easier to
> administer if you separate naming and permissions. We run a couple
> system with separate sysadmins and policy people. It's *much* easier
> to be able to give the first group write-access to the rules and the
> second group access to the permissions.

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.
 
> > Certainly this furthers the the purpose of centralization.
> 
> uh, and centralisation is what we should all strive for blindly,
> right?

Well the best of all possible worlds would be to make the use of
permissions.d optional.  Ideal design would be such that commenting out
udev_permissions in udev.conf would take it out of the config logic, but
putting it in would cause udev to use it.  The simpler, stricter syntax of
permissions.d files make them much easier to manage via scripting in higher
level tools.  This would make everyone happy, but given the issues already
raised, taking it out of the mix altogether may be the wisest choice.

> > Like you, I was reasonably impressed with the elegance and usefulness of the
> > facility in /etc/udev/permissions.d, however I also see problems with it. 
> 
> Care to elaborate?

See above :-)
 
Thanks to all, and season's greetings!

-- 
Lindsay Haisley       | "Fighting against human |     PGP public key
FMP Computer Services |    creativity is like   |      available at
512-259-1190          |    trying to eradicate  | <http://pubkeys.fmp.com>
http://www.fmp.com    |        dandelions"      |
                      |      (Pamela Jones)     |


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