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

[martin f krafft <madduck@madduck.net>]

[-- Attachment #1: Type: text/plain, Size: 7163 bytes --]

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.

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

> Gentoo uses similar structures - several of them.

Obviously.

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

> Certainly this furthers the the purpose of centralization.

uh, and centralisation is what we should all strive for blindly,
right?

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

> I happen to agree with the position that spec'd permissions should
> pass thru symlinks to the linked devices.  An admin who needs to
> set device permissions should be able to do so quickly and simply
> without reference to other resources to tell him whether said
> devices are symlinks or not.

Exactly.

> I also don't particularly care for design redundancy, and
> furthermore, although permissions.d is useful, it's overridden by
> values spec'd in udev rules files, which begins to get confusing.

The thing to do would thus be to enforce the permissions after the
rules (and hooks) had been processed.



also sprach Stefan Schweizer <sschweizer@gmail.com> [2004.12.18.1048 +0100]:
> If you look at the code you will see that removing permissions.d
> and keeping everything in rules.d will make the code more
> lightweight, make udevstart faster, and therefore startup for the
> udev users faster.

I care way more for ease of administration and security than faster
boot cycles. I reboot maybe twice a year; I administer a couple of
times a day. And security is important every fraction of a second.

> > 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. 
> 
> This is a prejudice against gregkh, what should he benefit from
> it? We are in a open source world here, not in a economic, where
> you have to compete. We will try to find a good solution for this,
> which is acceptible for all parties.

I absolutely agree, and I apologise if my statement came through as
prejudice towards Greg. In fact, I had not meant it personal at all,
and using the "bystander" indirection was done to prevent you from
thinking it was my opinion.

> > What is the benefit of merging permissions in with rules that
> > identify and name devices?
> > 
> It makes it just easier for the user. He/She does not have to look
> in 2 different locations,

Device and permission management are two separate parts of system
administration.

> he does not need to know the permissions.d syntax,

which is about 100 times easier than the rules.d syntax.

> he does not need to know about this extra file, he has one unified
> configuration interface. Its easier, lightweighter, faster ...
> just think about it once more.

Believe me, I have. I have been in the system administration
business for about as long as Linux exists. I have read many texts,
taught a number of courses, and had hours worth of discussion, in
system administration seminars and hallways tracks. System
administration is not about easy, lightweight, and fast. System
administration is about logical chunks, about staying in control,
about security, and about minimising the bookkeeping (and about some
other aspects).

> Gentoo uses /etc/conf.d for system init script configuration. But
> we have one unified configuration interface there, it is all
> CONFNAME="option", and not a different interface like the one in
> the permissions.d file, as that would confuse users.

Your users are confused by permissions.d syntax?

If yes, then just make permissions.d lines be like

  DEVICE="flash", OWNER="root", GROUP="flash", MODE="0660"

and you'll get your consistency.

> We should sort out our differences, and come to a decision,

Are you feeling that we are in the process of doing so?

> And after all I think even debian as the most widespread free
> distribution should hear why the udev maintainer denies something
> and not just make their own "debian-udev".

I am listening. I have not heard a good reason. I honestly have not.
I am not trying to be an arsehole or stubborn, but so far I have not
been convinced at all. If you think that merging permissions into
rules makes it simpler and more centralised, why then do you not
merge /etc/conf.d with /etc/init.d ?

Conversely, I think udev people should listen to Debian. This is not
about distros (and I am not going to discuss distros), but you
cannot deny that Debian has been often innovative, and has
substantially changed the way Linux administration happens. It's the
reason why so many professional admins like Debian, why so many
derivates build on our distro, and why we take so long to release.

permissions.d is good because it serves to separate device from
permission management. These two are different aspects of modern
system administration, and the more granular their separation, the
more flexible the solution will be.

There is *nothing* preventing you from writing a udev rules parser
plugin which generates permissions.d files, before udev then
enforces them. It's less trivial, however, to merge permissions.d in
which rules.d, just as it's easier to get e.g. a list of user home
directories from /etc/passwd into a separate file of uid:home pairs,
than it is to change each user's homedir in /etc/passwd from a file
of similar format.

-- 
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
 
"and if the cloud bursts, thunder in your ear
 you shout and no one seems to hear
 and if the band you're in starts playing different tunes
 i'll see you on the dark side of the moon."
                                                   -- pink floyd, 1972

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]