From: martin f krafft <madduck@madduck.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Bug#286040: please allow permissions.d to follow symlinks
Date: Sat, 18 Dec 2004 04:21:11 +0000 [thread overview]
Message-ID: <20041218042111.GA1962@cirrus.madduck.net> (raw)
In-Reply-To: <20041217083115.GA4050@wonderland.linux.it>
[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]
also sprach Greg KH <greg@kroah.com> [2004.12.18.0404 +0100]:
> So, on what "technological level" do you rank the current crop of
> distros (and by "crop" I mean ones that have had a release.)
I do not rank. Fact is that I will see whether Debian can continue
to use permissions.d and provide the symlink following I initially
requested, simply because I consider policy-based approaches to be
important. Without going comparative, this is going to put Debian on
a different level than other distros which go ahead to dump
permissions.d *with respect to* udev permission handling. This will
make it difficult to converge on a common set of rules.
You told me at Sucon '04 that (one of) your main beef(s) with Debian
is that we do not make patches with improvements available upstream.
I promised you I would look into this and try to improve the
situation. However, reading the archives, talking to Marco, and
looking at bugs, it seems to me that we are banging our heads
against the wall that you hold up, that you simply do not want our
patches. 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. Note that this is a bystander, I am
not accusing you of this. You will probably have to agree that it
could be interpreted as such.
I embrace permissions.d because it is in the same spirit that a lot
of things are done in Debian. Unless you give me technical reasons
(read: plain facts) why permissions.d is just wrong, I might be
inclined to support the bystander's opinion...
Why is it wrong to manage device permissions in a central location,
using a scheme that is intuitive to the user because it allows the
user to specify the desired state rather than having to think a lot.
flash:root:flash:0660
means: make the device available at /dev/flash readable only by root
and members of flash. Whether /dev/flash translates to /dev/sda1 or
/dev/your_mom or /dev/null... who cares?
If a user specifies the above and makes herself a member of flash
and then gets a permission denied error when trying to mount
/dev/flash because she wanted /dev/flash to be readable, not
/dev/whatever, then she will care.
What is the benefit of merging permissions in with rules that
identify and name devices?
If you answered that, please also think about the reasons why Fedora
uses /etc/sysconfig (and Gentoo probably does something similar).
> And why wouldn't all distros benifit from such a set of unified rules?
I am not at all denying this.
How to unify rules when there are differences in opinions?
--
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
"science without religion is lame,
religion without science is blind."
-- albert einstein
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-12-18 4:21 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-17 8:31 Bug#286040: please allow permissions.d to follow symlinks Marco d'Itri
2004-12-17 10:11 ` Stefan Schweizer
2004-12-17 10:48 ` martin f krafft
2004-12-17 13:24 ` Kay Sievers
2004-12-17 13:38 ` martin f krafft
2004-12-17 13:40 ` Marco d'Itri
2004-12-17 13:45 ` Kay Sievers
2004-12-17 13:47 ` Kay Sievers
2004-12-17 13:49 ` Marco d'Itri
2004-12-17 13:56 ` Kay Sievers
2004-12-17 13:58 ` martin f krafft
2004-12-17 14:13 ` Kay Sievers
2004-12-17 14:19 ` martin f krafft
2004-12-17 14:20 ` Kay Sievers
2004-12-17 14:35 ` martin f krafft
2004-12-17 14:36 ` Stefan Schweizer
2004-12-17 14:42 ` martin f krafft
2004-12-17 14:45 ` Kay Sievers
2004-12-17 14:52 ` martin f krafft
2004-12-17 15:50 ` Greg KH
2004-12-17 16:14 ` martin f krafft
2004-12-17 16:45 ` Greg KH
2004-12-17 17:10 ` martin f krafft
2004-12-17 17:45 ` Stefan Schweizer
2004-12-17 18:33 ` Greg KH
2004-12-17 18:40 ` martin f krafft
2004-12-17 23:25 ` Kay Sievers
2004-12-17 23:41 ` martin f krafft
2004-12-18 0:25 ` Lindsay Haisley
2004-12-18 0:53 ` martin f krafft
2004-12-18 1:18 ` martin f krafft
2004-12-18 3:04 ` Greg KH
2004-12-18 4:18 ` Lindsay Haisley
2004-12-18 4:21 ` martin f krafft [this message]
2004-12-18 9:48 ` Stefan Schweizer
2004-12-18 12:33 ` Tobias Klauser
2004-12-18 13:04 ` Marco d'Itri
2004-12-19 4:34 ` Randy.Dunlap
2004-12-20 9:39 ` martin f krafft
2004-12-20 17:56 ` Lindsay Haisley
2004-12-20 18:04 ` martin f krafft
2004-12-20 19:05 ` Lindsay Haisley
2004-12-21 8:04 ` martin f krafft
2004-12-21 16:11 ` Lindsay Haisley
2004-12-21 16:31 ` Lindsay Haisley
2004-12-21 16:38 ` martin f krafft
2004-12-21 16:48 ` Tobias Klauser
2004-12-21 16:54 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041218042111.GA1962@cirrus.madduck.net \
--to=madduck@madduck.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).