From mboxrd@z Thu Jan 1 00:00:00 1970 From: martin f krafft Date: Mon, 20 Dec 2004 09:39:50 +0000 Subject: Re: Bug#286040: please allow permissions.d to follow symlinks Message-Id: <20041220093950.GA31170@cirrus.madduck.net> MIME-Version: 1 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" List-Id: References: <20041217083115.GA4050@wonderland.linux.it> In-Reply-To: <20041217083115.GA4050@wonderland.linux.it> To: linux-hotplug@vger.kernel.org --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Answering multiple mails in one... scroll down... also sprach Lindsay Haisley [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.= =20 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 [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.=20 >=20 > 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? > >=20 > 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=3D"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=3D"flash", OWNER=3D"root", GROUP=3D"flash", MODE=3D"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. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "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 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBxp3mIgvIgzMMSnURAgTmAKDTB/ZMA9WH7tBkHIyV8PjqMZvvtwCfVYwR 08A9R8DaTOBPiP+ReGWyqbM= =f6HV -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- ------------------------------------------------------- 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