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

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

[Marco d'Itri]

----- Forwarded message from martin f krafft <madduck@debian.org> -----

Subject: Bug#286040: please allow permissions.d to follow symlinks
Reply-To: martin f krafft <madduck@debian.org>, 286040@bugs.debian.org
From: martin f krafft <madduck@debian.org>

Package: udev
Version: 0.048-2
Severity: wishlist
Tags: upstream

A rule like

  BUS="scsi", SYSFS\{model\}="FLASH", KERNEL="sd?1", NAME="%k", SYMLINK="flash"

works, but a corresponding entry like

  flash:root:flash:0660

in a permissions.d file does not -- it tries to change the
permissions of the symlink instead. Permissions on a symlink are
irrelevant, so I suggest that udev instead follows the symlink
before applying permissions.

Thanks,

[...]

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!



----- End forwarded message -----

-- 
ciao, |
Marco | [9855 cow8caHUN5tm2]


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

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

[Stefan Schweizer]

On Fri, 17 Dec 2004 09:31:15 +0100, Marco d'Itri <md@linux.it> wrote:
> ----- Forwarded message from martin f krafft <madduck@debian.org> -----
> 
> Subject: Bug#286040: please allow permissions.d to follow symlinks
> Reply-To: martin f krafft <madduck@debian.org>, 286040@bugs.debian.org
> From: martin f krafft <madduck@debian.org>
> 
> Package: udev
> Version: 0.048-2
> Severity: wishlist
> Tags: upstream
> 
> A rule like
> 
>   BUS="scsi", SYSFS\{model\}="FLASH", KERNEL="sd?1", NAME="%k", SYMLINK="flash"
> 
> works, but a corresponding entry like
> 
>   flash:root:flash:0660
> 
> in a permissions.d file does not -- it tries to change the
> permissions of the symlink instead. Permissions on a symlink are
> irrelevant, so I suggest that udev instead follows the symlink
> before applying permissions.
> 

See http://bugs.gentoo.org/show_bug.cgi?ids064 for a patch
I think it is worth to implement this functionality.

Thanks,
Stefan


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

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

[martin f krafft]

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

tags 286040 + patch
thanks

also sprach Marco d'Itri <md@Linux.IT> [2004.12.17.0931 +0100]:
>   flash:root:flash:0660
> 
> in a permissions.d file does not -- it tries to change the
> permissions of the symlink instead. Permissions on a symlink are
> irrelevant, so I suggest that udev instead follows the symlink
> before applying permissions.

As pointed out by Stefan Schweizer (see bug report):
  http://bugs.gentoo.org/show_bug.cgi?id=73064

-- 
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
 
"all unser übel kommt daher,
 daß wir nicht allein sein können."
                                                       -- schopenhauer

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 09:31 +0100, Marco d'Itri wrote:
> ----- Forwarded message from martin f krafft <madduck@debian.org> -----
> 
> A rule like
> 
>   BUS="scsi", SYSFS\{model\}="FLASH", KERNEL="sd?1", NAME="%k", SYMLINK="flash"
> 
> works, but a corresponding entry like
> 
>   flash:root:flash:0660
> 
> in a permissions.d file does not -- it tries to change the
> permissions of the symlink instead. Permissions on a symlink are
> irrelevant, so I suggest that udev instead follows the symlink
> before applying permissions.

Why you guys always want to make things more complicated as needed?

Just specify the permissions in the rule itself like ide-devfs.sh is
doing it or use the name you want to use in the NAME key and not in a
SYMLINK and everything will work as expected.

Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1424 +0100]:
> Why you guys always want to make things more complicated as
> needed?

You mean "less complicated"? Because we are Debian and therefore
make sure that things just work the way they are supposed to, no
more and no less. There is no point in changing symlink permissions.
What a user wants to do instead is change the permissions of the
device. So we should allow him/her to do so intuitively.

Why bother having to use commands explicitly when there is already
a framework to do exactly that? Even if the framework has to be
extended, it's better to make use of it than to reinvent several
other wheels.

Or: why bother using cron when you could just as well write your own
daemon to regularly spawn your process? Think UNIX, think
modularity, think flexibility, think power: each tool for its own
purpose, no more, no less.

> Just specify the permissions in the rule itself like ide-devfs.sh
> is doing it or use the name you want to use in the NAME key and
> not in a SYMLINK and everything will work as expected.

That is one possibility. However, I see some (albeit weak) arguments
for using symlinks, as it does not degrade functionality but
provides more information and more flexibility. After all, the
kernel log will, e.g. reference /dev/sda1, and if that is not
present, it may be confusing. Also, Having /dev/sda and /dev/sda1 in
addition to /dev/flash makes more sense than having only /dev/sda
and /dev/flash.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Marco d'Itri]

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

On Dec 17, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Why you guys always want to make things more complicated as needed?
Correctly handling permissions of symlinked nodes is consistency, not
complexity.
There is no reason to change the link owner or permissions, so it should
be obvious that it's the linked file which should be changed.

-- 
ciao, |
Marco | [9876 seJzaYXFfXXiU]

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 14:38 +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1424 +0100]:
> > Why you guys always want to make things more complicated as
> > needed?
> 
> You mean "less complicated"? Because we are Debian and therefore
> make sure that things just work the way they are supposed to, no
> more and no less. There is no point in changing symlink permissions.
> What a user wants to do instead is change the permissions of the
> device. So we should allow him/her to do so intuitively.
> 
> Why bother having to use commands explicitly when there is already
> a framework to do exactly that? Even if the framework has to be
> extended, it's better to make use of it than to reinvent several
> other wheels.

Symlinks should not have any impact on the node. That's the concept,
that makes more sense to me than the proposed magic.

Kay



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

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

[Kay Sievers]

On Fri, 2004-12-17 at 14:40 +0100, Marco d'Itri wrote:
> On Dec 17, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > Why you guys always want to make things more complicated as needed?
> Correctly handling permissions of symlinked nodes is consistency, not
> complexity.
> There is no reason to change the link owner or permissions, so it should
> be obvious that it's the linked file which should be changed.

So, where do we change the owner of a symlink? I will fix this!

Kay



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

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

[Marco d'Itri]

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

On Dec 17, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > There is no reason to change the link owner or permissions, so it should
> > be obvious that it's the linked file which should be changed.
> So, where do we change the owner of a symlink? I will fix this!
When one is listed in udev.permissions.

-- 
ciao, |
Marco | [9877 riMJ9kmns06z6]

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 14:49 +0100, Marco d'Itri wrote:
> On Dec 17, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > > There is no reason to change the link owner or permissions, so it should
> > > be obvious that it's the linked file which should be changed.
> > So, where do we change the owner of a symlink? I will fix this!
> When one is listed in udev.permissions.

So please point me to the code that can do what you claim.

Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1445 +0100]:
> Symlinks should not have any impact on the node. That's the
> concept, that makes more sense to me than the proposed magic.

Feel free to submit a patch which provides a better fix to the
framework. Do not expect every user entry to reinvent the wheel,
please.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 14:58 +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1445 +0100]:
> > Symlinks should not have any impact on the node. That's the
> > concept, that makes more sense to me than the proposed magic.
> 
> Feel free to submit a patch which provides a better fix to the
> framework. Do not expect every user entry to reinvent the wheel,
> please.

There is nothing I can see the need for a fix. It is intentional that
the symlinks never change the specified behavior of the node. As said,
there is the easy way to specify explicit rule permissions if needed.

Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1513 +0100]:
> There is nothing I can see the need for a fix. It is intentional
> that the symlinks never change the specified behavior of the node.
> As said, there is the easy way to specify explicit rule
> permissions if needed.

Just as you fail to understand our position, I fail to understand
your arguments. Why (or where) is it intentional that a chmod on
a symlink created by udev does not affect the actual device?
Moreover, what would be the real point of that? What's the point of
permissions on a symlink?

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 15:19 +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1513 +0100]:
> > There is nothing I can see the need for a fix. It is intentional
> > that the symlinks never change the specified behavior of the node.
> > As said, there is the easy way to specify explicit rule
> > permissions if needed.
> 
> Just as you fail to understand our position, I fail to understand
> your arguments. Why (or where) is it intentional that a chmod on
> a symlink created by udev does not affect the actual device?
> Moreover, what would be the real point of that? What's the point of
> permissions on a symlink?

Can you read code?
If yes, please point me to the chmod() of a symlink. I will fix it.

Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1520 +0100]:
> Can you read code?

Depends on who wrote it.

> If yes, please point me to the chmod() of a symlink. I will fix it.

I was giving an example. udev currently obtains the permissions to
use on node creation from the permissions.d list. Symlinks are
created without special permissions, or reference to the permissions
list.

If you ask me, permissions.d list should be extended by inner join
with the symlinks list for each node. Then I would not have to touch
symlinks and only the actual device pointed to gets changed.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Stefan Schweizer]

Just look in  /etc/udev/permissions.d/50-udev.permissions

# optical devices
sr*:root:cdrom:660
scd*:root:cdrom:660
pcd*:root:cdrom:0660
cdrom*:root:cdrom:0660
dvd:root:cdrom:0660
rdvd:root:cdrom:0660
cdroms/*:root:cdrom:0660


for example all of these point to symlinks and do nothing currently,
so we should
a) make them do something
b) remove them 

There are sure more of them, but this is the most common example.
pam hided these problems, because it changes the permissions when a
user logs in.
I made a patch to solve this with a GROUP="" statement, whcih is now
used in gentoos udev. But I think its ugly design, because permissions
should be kept in permissions.d and not in rules.d, and you can even
have more advanced rules then, making the group cdrw based on if a
symlink to that exists.

Stefan


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

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

[martin f krafft]

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

also sprach Stefan Schweizer <sschweizer@gmail.com> [2004.12.17.1536 +0100]:
> There are sure more of them, but this is the most common example.
> pam hided these problems, because it changes the permissions when
> a user logs in.

... which is ultimately asking for troubles...

> I made a patch to solve this with a GROUP="" statement, whcih is
> now used in gentoos udev. But I think its ugly design, because
> permissions should be kept in permissions.d and not in rules.d,
> and you can even have more advanced rules then, making the group
> cdrw based on if a symlink to that exists.

Excellent point.

PS: Please use 286040-quiet@ instead of 286040@ in the CC, since
Marco reads linux-hotplug-devel anyway. Also, I would appreciate not
being included in the CC, as I read the list as well. My
Mail-Followup-To header should be set appropriately.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 15:35 +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1520 +0100]:
> > Can you read code?
> 
> Depends on who wrote it.

Mostly me.

> > If yes, please point me to the chmod() of a symlink. I will fix it.
> 
> I was giving an example.

And where is the pointer to the code to proof your loud/proud claim?

> udev currently obtains the permissions to
> use on node creation from the permissions.d list. Symlinks are
> created without special permissions, or reference to the permissions
> list.

Right.

> If you ask me, permissions.d list should be extended by inner join
> with the symlinks list for each node. Then I would not have to touch
> symlinks and only the actual device pointed to gets changed.

I don't ask you. Please try to convince somebody else. For my part, I've
made my points clear: The addition of symlinks should never affect the
specified behavior of the device node.

Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1545 +0100]:
> > > If yes, please point me to the chmod() of a symlink. I will
> > > fix it.
> > I was giving an example.
> And where is the pointer to the code to proof your loud/proud
> claim?

Why do you need a pointer? Please consider standard usage scenarios
instead!

You are defending the integrity of your code when I try to tell you
that it does not optimally service the user. Your code is fine, I am
arguing that you should take a different perspective to permissions
management: a perspective that is pragmatic, not theoretical and
pedantic.

> > If you ask me, permissions.d list should be extended by inner
> > join with the symlinks list for each node. Then I would not have
> > to touch symlinks and only the actual device pointed to gets
> > changed.
> 
> I don't ask you. Please try to convince somebody else.

Oh bother, why is it that open source developers always assume that
they are smarter than the rest of the world?

> For my part, I've made my points clear: The addition of symlinks
> should never affect the specified behavior of the device node.

... unless the administrator specifies permissions to be used for
the device identified by the symlink.

-- 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

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

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

[Greg KH]

On Fri, Dec 17, 2004 at 03:52:11PM +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.17.1545 +0100]:
> > > > If yes, please point me to the chmod() of a symlink. I will
> > > > fix it.
> > > I was giving an example.
> > And where is the pointer to the code to proof your loud/proud
> > claim?
> 
> Why do you need a pointer? Please consider standard usage scenarios
> instead!
> 
> You are defending the integrity of your code when I try to tell you
> that it does not optimally service the user. Your code is fine, I am
> arguing that you should take a different perspective to permissions
> management: a perspective that is pragmatic, not theoretical and
> pedantic.

Oh my word.

Sorry, but Kay is correct.  udev isn't going to be changed to modify the
permissions of the target of the symlink.  udev has the capability to
properly change the permissions based on a rule or a external program.
Please use that facitilty to do what you want it to do.

> > > If you ask me, permissions.d list should be extended by inner
> > > join with the symlinks list for each node. Then I would not have
> > > to touch symlinks and only the actual device pointed to gets
> > > changed.
> > 
> > I don't ask you. Please try to convince somebody else.
> 
> Oh bother, why is it that open source developers always assume that
> they are smarter than the rest of the world?

When obviously, the open source users are the smarter ones.  Sorry for
forgetting this fact.

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

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

[martin f krafft]

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

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

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

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

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.

-- 
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
 
$complex->{'data'}[$structures][$in_perl] = @{$can{'be'}->[$painful]};

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

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

[Greg KH]

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

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

[martin f krafft]

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

also sprach Greg KH <greg@kroah.com> [2004.12.17.1745 +0100]:
> 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.

mh. I must work on improving my English comprehension skills then.

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

Oh great. Reverse evolution.

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

Yes, vehemently. It has caused way too much trouble.

From the README:

  "Please note: the current version depends on too many external
  tools and libraries, making it big and hard to evaluate for
  security."

http://www.i-eye.net/exploits/pam_console.c.php

It may work for your one-user desktop system. Any other use is
dangerous. There must be a reason why it's not part of libpam.

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

I might provide it. However, so far the feedback has been that
I should instead bugger off and get a clue. So instead I think
I will feed it into Debian and see if it's useful. You can always
come and ask for it should I forget to submit it here.

-- 
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
 
"in the stage of grand illusion
 you walked into my life
 out of my dreams."
                                                        -- david bowie

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

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

[Stefan Schweizer]

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

On Fri, 17 Dec 2004 08:45:48 -0800, Greg KH <greg@kroah.com> wrote:
> 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.

This sounds cool, but it will also mean, that we have bigger rules, as
most of the rules will need a GROUP="" statement then.

> What about the fun interaction with pam that causes device nodes to
> "magically" assume other permissions.  Are you objecting to that too?
> 
That has nothing to do with udev, it only hided an udev bug for a while

If you look in your archives, you will see, that I first wanted to
make permissions.d follow symlinks as the proper way to handle it. As
I consider myself not a very good programmer and because someone
pointed out that I could use GROUP=, I made a workaround that has been
merged into udev now.
But I still think its abetter to make udev follow symlinks as that
will keep permissions in permissions.d and remove unnecessary grouping
code from symlink-scripts like cdsymlinks.sh.

> 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.
> 
I attached a rolled-up patch against the latest udev release for your pleasure.
It was taken from http://bugs.gentoo.org/show_bug.cgi?id=73064
You can credit Gregorio Guidi <g.guidi <at> sns.it> for it, when you merge it.

> Um, I have no control over the debian udev rules files, I just mirror in
> the udev tree what the maintainer gives to me.
> 
I use gentoo, but why do we even have different rules.d files? Can we
not make as much as possible common in them? What are the differences
between the distributions?
With this system we have some rules missing in every distributions
rules file, because bugfixes and new features are commonly applied
only to one rules file.

Stefan Schweizer
Gentoo developer
http://dev.gentoo.org/~genstef

[-- Attachment #2: udev-match-symlink-perms.patch --]
[-- Type: application/octet-stream, Size: 1308 bytes --]

diff -uNr udev-049.orig/etc/udev/gentoo/udev.permissions udev-046/etc/udev/udev.permissions.gentoo
--- udev-049.orig/etc/udev/gentoo/udev.permissions	2004-11-18 20:39:15.000000000 +0100
+++ udev-049/etc/udev/gentoo/udev.permissions	2004-12-01 21:22:15.095677080 +0100
@@ -114,7 +114,6 @@
 raw/*:root:disk:660
 
 # disk devices
-hd*:root:disk:660
 sd*:root:disk:660
 dasd*:root:disk:660
 ataraid*:root:disk:660
diff -uNr udev-049.orig/namedev.c udev-046/namedev.c
--- udev-049.orig/namedev.c	2004-11-18 20:39:15.000000000 +0100
+++ udev-049/namedev.c	2004-12-01 21:18:42.945928744 +0100
@@ -695,7 +695,9 @@
 	struct sysfs_device *sysfs_device = NULL;
 	struct config_device *dev;
 	struct perm_device *perm;
+	char linkname[NAME_SIZE];
 	char *pos;
+	int len;
 
 	udev->mode = 0;
 	dbg("class_dev->name='%s'", class_dev->name);
@@ -794,6 +796,18 @@
 perms:
 	/* apply permissions from permissions file to empty fields */
 	perm = find_perm_entry(udev->name);
+	if (perm != NULL)
+		goto perms_found;
+
+	/* try to match the symlink name */
+	foreach_strpart(udev->symlink, " ", pos, len) {
+		strfieldcpymax(linkname, pos, len+1);
+		perm = find_perm_entry(linkname);
+		if (perm != NULL)
+			goto perms_found;
+	}
+
+perms_found:
 	if (perm != NULL) {
 		if (udev->mode == 0000)
 			udev->mode = perm->mode;

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

[Greg KH]

On Fri, Dec 17, 2004 at 06:45:00PM +0100, Stefan Schweizer wrote:
> On Fri, 17 Dec 2004 08:45:48 -0800, Greg KH <greg@kroah.com> wrote:
> > 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.
> 
> This sounds cool, but it will also mean, that we have bigger rules, as
> most of the rules will need a GROUP="" statement then.

That is true.

> > Um, I have no control over the debian udev rules files, I just mirror in
> > the udev tree what the maintainer gives to me.
> > 
> I use gentoo, but why do we even have different rules.d files? Can we
> not make as much as possible common in them? What are the differences
> between the distributions?

Unfortunatly, lots of little things.

> With this system we have some rules missing in every distributions
> rules file, because bugfixes and new features are commonly applied
> only to one rules file.

Very true.  Any help in making sure all rules are in all distro files is
greatly appreciated.

thanks,

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

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

[martin f krafft]

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

also sprach Greg KH <greg@kroah.com> [2004.12.17.1933 +0100]:
> Very true.  Any help in making sure all rules are in all distro files is
> greatly appreciated.

This requires all distros to adhere to a common set of standards,
and be on the same technological level. If you ask me, this is not
the case.

-- 
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
 
"si tu veux construire un bateau, il ne faut pas réunir des hommes
pour aller chercher le bois et les outils et les préparer à se
répartir les différents travaux. Il faut plutôt leur donner l'envie,
la passion de la mer infinie."
                                           -- antoine de saint-exupéry

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

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

[Kay Sievers]

On Fri, 2004-12-17 at 08:45 -0800, Greg KH wrote:
> 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.

Nice idea, sounds good to me. It will make the whole process more
transparent. And we don't need to open and parse a whole file/directory
which may still be a win over the increased rules size.

Any objections against it? I may give it a try...

Thanks,
Kay



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

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

[martin f krafft]

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

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.18.0025 +0100]:
> Any objections against it? I may give it a try...

Please make sure to remove any mention of "policy" and "permission"
in the same paragraph in comments and documentation.

-- 
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
 
         EARTH
      smog | bricks
 AIR  --  mud  -- FIRE
soda water | tequila
         WATER

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

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

[Lindsay Haisley]

Thus spake Kay Sievers on Fri, Dec 17, 2004 at 05:25:21PM CST
> On Fri, 2004-12-17 at 08:45 -0800, Greg KH wrote:
> > 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.
> 
> Nice idea, sounds good to me. It will make the whole process more
> transparent. And we don't need to open and parse a whole file/directory
> which may still be a win over the increased rules size.
> 
> Any objections against it? I may give it a try...

I was going to post and suggest that this is the logical solution, but not
being a developer I hesitated.  Nonetheless, from a system administrator's
point of view, minimizing functional redundancy (unless the components are
"basic building blocks") is a Good Thing, and makes the configuration
process simpler and faster, which is also a Good Thing for busy sysadmins.

IMHO, designing in accord with the KISS principle is seldom an evolutionary
step backwards.

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

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

[martin f krafft]

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

also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.18.0125 +0100]:
> IMHO, designing in accord with the KISS principle is seldom an
> evolutionary step backwards.

I agree that no permissions.d is better than not allowing nodes
identified by symlinks to be changed.

However, I also think that having a central place to configure
device permissions is favourable. Without udev, I can do that in
/dev. With udev, I will now have to scan all rules, possibly dive
into scripts and essentially pretend I am a shell script processor
to figure out which permissions are actually being applied.

If you come from the system administration background, I wonder how
you see a benefit in this approach! Are you aware of what
policy-based approaches are, what they try to solve, and why they
are a great idea, in programming, security management, or system
administration?

Why do you think Debian has /etc/default and Fedora uses
/etc/sysconfig (to give just two very trivial examples -- I am
sorry, I am unaware of how Gentoo does things, but I assume them to
be similar)? We are not getting rid of these because they fulfill
a very specific purpose: centralise configurable aspects of the
System V init process. The performance impact they produce is
negligible given how they facilitate administration.

When I saw permissions.d, I was rather impressed by its elegance
(very reminiscent of how Debian does many things, actually -- yes,
I am biased ;^>). How sad to have the developers turn around and
stick their heads in the sand for no real reason.

-- 
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
 
this product is under strict quality contril with perfect packing and
quality when leving the factory.please keep away from damp.high
temperature or sun expose.If found any detectives when purchasing.
please return the productby airmail to our administration section and
inform the time, place.and store of this purchase for our
improvement.We shall give you a satisfactory reply.Thanks for your
patronage and welcome your comments.
                                                     -- http://www.engrish.com

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

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

[martin f krafft]

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

also sprach martin f krafft <madduck@madduck.net> [2004.12.18.0153 +0100]:
> How sad to have the developers turn around and
> stick their heads in the sand for no real reason.

... and it all looked so promising:

  -- Additional Comment #12 From Greg KH  2004-12-15 16:24 PST --
  Will fix in next udev release.

(http://bugs.gentoo.org/show_bug.cgi?id=73064)

The bug report references
  http://bugs.gentoo.org/attachment.cgi?id=45074

which is not a good solution, but maybe a step in the right
direction.

-- 
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
 
"be the change you want to see in the world"
                                                     -- mahatma gandhi

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

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

[Greg KH]

On Fri, Dec 17, 2004 at 07:40:23PM +0100, martin f krafft wrote:
> also sprach Greg KH <greg@kroah.com> [2004.12.17.1933 +0100]:
> > Very true.  Any help in making sure all rules are in all distro files is
> > greatly appreciated.
> 
> This requires all distros to adhere to a common set of standards,
> and be on the same technological level. If you ask me, this is not
> the case.

So, on what "technological level" do you rank the current crop of
distros (and by "crop" I mean ones that have had a release.) 

And why wouldn't all distros benifit from such a set of unified rules?

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

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

[Lindsay Haisley]

Thus spake martin f krafft on Fri, Dec 17, 2004 at 06:53:58PM CST
> also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.18.0125 +0100]:
> > IMHO, designing in accord with the KISS principle is seldom an
> > evolutionary step backwards.
> 
> I agree that no permissions.d is better than not allowing nodes
> identified by symlinks to be changed.
> 
> However, I also think that having a central place to configure
> device permissions is favourable. Without udev, I can do that in
> /dev. With udev, I will now have to scan all rules, possibly dive
> into scripts and essentially pretend I am a shell script processor
> to figure out which permissions are actually being applied.
> 
> If you come from the system administration background, I wonder how
> you see a benefit in this approach! Are you aware of what
> policy-based approaches are, what they try to solve, and why they
> are a great idea, in programming, security management, or system
> administration?

I do not come from a "systems administration background".  I am an educated
human being who makes his living from providing Internet services that
others want and need, and have had to learn what I need to know to make it
happen.  I really don't give a rip about "policy-based approaches".  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.
I expect the documentation to readily available, logically presented, and to
use defined terms and referenced concepts to provide a clear and useful path
into the facility it documents.  

I respect the capabilities of the developers who have put a great deal of
their time, effort, and above all their commitment to excellence into the
design of systems such as udev, and, while I may make suggestions from time
to time, I do not in any way presume to pass judgement on their efforts.

> Why do you think Debian has /etc/default and Fedora uses
> /etc/sysconfig (to give just two very trivial examples -- I am
> sorry, I am unaware of how Gentoo does things, but I assume them to
> be similar)?

Gentoo uses similar structures - several of them.

> We are not getting rid of these because they fulfill
> a very specific purpose: centralise configurable aspects of the
> System V init process. The performance impact they produce is
> negligible given how they facilitate administration.

I see no problem with having owner, group and mode spec'd in udev rules
files. Certainly this furthers the the purpose of centralization.  The
syntax of the file is reasonably forgiving, and anyone wanting a greater
degree of order could format it to personal taste so as to make it more
readable.
 
> When I saw permissions.d, I was rather impressed by its elegance
> (very reminiscent of how Debian does many things, actually -- yes,
> I am biased ;^>). How sad to have the developers turn around and
> stick their heads in the sand for no real reason.

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.  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.  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.  Things could be simpler, and it
looks as if Greg, Kay & others are on the right track.
 
-- 
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

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

[martin f krafft]

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

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

[Stefan Schweizer]

On Sat, 18 Dec 2004 05:21:11 +0100, martin f krafft <madduck@madduck.net> wrote:
> 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.
> 

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.

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

I think every maintainer does not just merge patches, but thinks about
what they do, and maybe better solutions, how the goal could be
achieved. Thing is, that patches, which are not send upstream never
get discussed or reviewed and therefore have a much less code quality.
> 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.

> 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, he does not need to know the permissions.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.

> If you answered that, please also think about the reasons why Fedora
> uses /etc/sysconfig (and Gentoo probably does something similar).

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.

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

We should sort out our differences, and come to a decision, that is
acceptable for everybody. It shouldnt be that hard to have one
configuration interface in all distros and not one for every distro.
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".

Kind regards,
Stefan


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

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

[Tobias Klauser]

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

On Friday 17 December 2004 14:40, Marco d'Itri wrote:
> On Dec 17, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > Why you guys always want to make things more complicated as needed?
>
> Correctly handling permissions of symlinked nodes is consistency, not
> complexity.
> There is no reason to change the link owner or permissions, so it should
> be obvious that it's the linked file which should be changed.

How about just making this a "configurable" option e.g. in udev.conf? So the 
distribution or the user can specifiy wether udev should "follow" symlinks 
when applying permissions or not.

Something like:

follow_symlinks="yes" to apply permissions also to the symlinked node
or
follow_symlinks="no" to apply permissions only to the symlink itself

It might be more complicated than that but I'm not really into the udev source 
code eventough I hope you get the point.

	Tobias

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

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

[Marco d'Itri]

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

On Dec 18, Tobias Klauser <tklauser@access.unizh.ch> wrote:

> follow_symlinks="no" to apply permissions only to the symlink itself
This would be meaningless, there is no need for new configuration
directives.

-- 
ciao, |
Marco | [9896 ar6nHmgQMqUF.]

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

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

[Randy.Dunlap]

Greg KH wrote:
> On Fri, Dec 17, 2004 at 07:40:23PM +0100, martin f krafft wrote:
> 
>>also sprach Greg KH <greg@kroah.com> [2004.12.17.1933 +0100]:
>>
>>>Very true.  Any help in making sure all rules are in all distro files is
>>>greatly appreciated.
>>
>>This requires all distros to adhere to a common set of standards,
>>and be on the same technological level. If you ask me, this is not
>>the case.
> 
> 
> So, on what "technological level" do you rank the current crop of
> distros (and by "crop" I mean ones that have had a release.) 
> 
> And why wouldn't all distros benifit from such a set of unified rules?

and why wouldn't users who happen to use more than one distro?

-- 
~Randy


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

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

[martin f krafft]

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

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

[Lindsay Haisley]

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

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

[martin f krafft]

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

also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.20.1856 +0100]:
> 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.

Uh, are you arguing for or against permissions.d now?

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

On all systems that I have, the only changes I made to the default
udev ruleset were adjusting permissions. For all I care, rules.d
could be in /usr/share and /etc/udev/rules.d could just as well be
empty... if permissions.d is available.

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

Is it? Is a discussion closed if some of the involved parties simply
refuse to discuss for no reason other than "no, i will not consider
this?"

Making permissions.d optional would be okay, but then please make it
take precedence.

-- 
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
 
"man soll nicht in kirchen gehn, wenn man reine luft atmen will."
                                                 - friedrich nietzsche

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

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

[Lindsay Haisley]

Thus spake martin f krafft on Mon, Dec 20, 2004 at 12:04:16PM CST
> > 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.
> 
> Is it? Is a discussion closed if some of the involved parties simply
> refuse to discuss for no reason other than "no, i will not consider
> this?"
> 
> Making permissions.d optional would be okay, but then please make it
> take precedence.

If it's optional, then it ought to take precedence as far as owner/mode
issues are concerned, and IMHO owner/mode settings in the permissions file
should pass through symlinks to their targets ('scuse me, Greg!)

The only other complicating issue here, as far as Gentoo is concerned, is
the use of RC_DEVICE_TARBALL in /etc/conf.d/rc.  If this is turned on, I
believe that whatever is stored in it from the last shutdown pretty much
trumps everything as far as owner/mode issues are concerned, at least as far
as boot-time device config is concerned.  Until all device modules from all
vendors support sysfs then this may be necessary.  Red Hat and other distros
use other methods, but the issue is probably the same.

I use RC_DEVICE_TARBALL to store and retrieve VMware devices.  The VMware
devs have expressed their dislike for sysfs and don't want to work with it,
and unless one creates the devices manually or by some sort of script on
each system boot, they don't get created by the VMware kernel modules.

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

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

[martin f krafft]

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

also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.20.2005 +0100]:
> as boot-time device config is concerned.  Until all device modules from all
> vendors support sysfs then this may be necessary.  Red Hat and other distros
> use other methods, but the issue is probably the same.

As it sounds like a workaround, sure, it should take precedence.

> I use RC_DEVICE_TARBALL to store and retrieve VMware devices. 

Why not define custom rules? Or is it just not possible without
sysfs support?

Then maybe you want to add a modutils hook?

-- 
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
 
DISCLAIMER: this entire message is privileged communication, intended
for the sole use of its recipients only. If you read it even though
you know you aren't supposed to, you're a poopy-head.

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

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

[Lindsay Haisley]

Thus spake martin f krafft on Tue, Dec 21, 2004 at 02:04:13AM CST
> also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.20.2005 +0100]:
> > as boot-time device config is concerned.  Until all device modules from all
> > vendors support sysfs then this may be necessary.  Red Hat and other distros
> > use other methods, but the issue is probably the same.
> 
> As it sounds like a workaround, sure, it should take precedence.
> 
> > I use RC_DEVICE_TARBALL to store and retrieve VMware devices. 
> 
> Why not define custom rules? Or is it just not possible without
> sysfs support?
> 
> Then maybe you want to add a modutils hook?

Yes, you're right.  I could use a modules post-install to create the
devices.  In the case of VMware, I could also put appropriate mknod's in
/etc/init.d/vmware, which is what the VMware people suggest.  I think I
needed to get my guest OS up and running in a hurry, maybe to do my monthly
billing or some such and using RC_DEVICE_TARBALL was quick and easy. 
Because The VMware kernel modules don't support sysfs at all, I don't think
it's possible to do a workaround in any kind of udev rule.

FYI, here's the word on udev and sysfs from one of the VMware folks on the
VMware community forum:

> 1. Is there likely to be an evolution of VMWare to
> be compatible with udev?

There is bug filled on this, but problem is that vmware supports
vmnet0-vmnet255 - and we do not want to pollute /dev with them, as normal
people need only 2 or 3. In future vmnet will use just one multiplexing
device, like Windows's vmnet does, but until then likelihood of udev being
supported is rather low. Maybe if SuSE 9.2/10 or RHEL4 will use udev,
something will have to be done about it, but I find sysfs really ugly and
hard to use.

> 2. Is setting up /dev/vmnet0 just a question of
> running MAKEDEV with the appropriate major and minor
> device numbers? (So that reconstructing the kernel
> modules can be avoided.)

Yes. Just place appropriate mknod somewhere - probably beginning of
/etc/init.d/vmware is best place for them.

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

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

[Lindsay Haisley]

Thus spake Lindsay Haisley on Tue, Dec 21, 2004 at 10:11:06AM CST
> Thus spake martin f krafft on Tue, Dec 21, 2004 at 02:04:13AM CST
> > also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.20.2005 +0100]:
> > > as boot-time device config is concerned.  Until all device modules from all
> > > vendors support sysfs then this may be necessary.  Red Hat and other distros
> > > use other methods, but the issue is probably the same.
> > 
> > As it sounds like a workaround, sure, it should take precedence.
> > 
> > > I use RC_DEVICE_TARBALL to store and retrieve VMware devices. 
> > 
> > Why not define custom rules? Or is it just not possible without
> > sysfs support?
> > 
> > Then maybe you want to add a modutils hook?
> 
> Yes, you're right.  I could use a modules post-install to create the
> devices.  In the case of VMware, I could also put appropriate mknod's in
> /etc/init.d/vmware, which is what the VMware people suggest.  I think I
> needed to get my guest OS up and running in a hurry, maybe to do my monthly
> billing or some such and using RC_DEVICE_TARBALL was quick and easy. 
> Because The VMware kernel modules don't support sysfs at all, I don't think
> it's possible to do a workaround in any kind of udev rule.

The point is that as long as Gentoo provides this feature, which overrides
udev rules at boot then udev is potentially only useful for configuring hot
plugged devices on a running system and the question of udev rules and
permissions.d for setting boot-time options is moot.

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

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

[martin f krafft]

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

also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.21.1731 +0100]:
> The point is that as long as Gentoo provides this feature, which
> overrides udev rules at boot then udev is potentially only useful
> for configuring hot plugged devices on a running system and the
> question of udev rules and permissions.d for setting boot-time
> options is moot.

... for Gentoo systems, yes.

Anyway, since the tarball thingie really just defeats the purpose of
udev, I doubt that Gentoo will support it much longer.

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

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

[Tobias Klauser]

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

On Tuesday 21 December 2004 17:38, martin f krafft wrote:
> also sprach Lindsay Haisley <fmouse-gentoo@fmp.com> [2004.12.21.1731 +0100]:
> > The point is that as long as Gentoo provides this feature, which
> > overrides udev rules at boot then udev is potentially only useful
> > for configuring hot plugged devices on a running system and the
> > question of udev rules and permissions.d for setting boot-time
> > options is moot.
>
> ... for Gentoo systems, yes.
>
> Anyway, since the tarball thingie really just defeats the purpose of
> udev, I doubt that Gentoo will support it much longer.

AFAIK the tarball was only a workaround for older udev versions on which some 
nodes (e.g. /dev/console which is needed for booting) were missing during 
bootup. I guess they're fixed now and there is no problem running udev 
without the tarball.

Thanks, Tobias

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

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

[Greg KH]

On Tue, Dec 21, 2004 at 10:11:06AM -0600, Lindsay Haisley wrote:
> FYI, here's the word on udev and sysfs from one of the VMware folks on the
> VMware community forum:
> 
> > 1. Is there likely to be an evolution of VMWare to
> > be compatible with udev?
> 
> There is bug filled on this, but problem is that vmware supports
> vmnet0-vmnet255 - and we do not want to pollute /dev with them, as normal
> people need only 2 or 3. In future vmnet will use just one multiplexing
> device, like Windows's vmnet does, but until then likelihood of udev being
> supported is rather low. Maybe if SuSE 9.2/10 or RHEL4 will use udev,
> something will have to be done about it, but I find sysfs really ugly and
> hard to use.

SuSE 9.2 and RHEL 4 use udev :)

> > 2. Is setting up /dev/vmnet0 just a question of
> > running MAKEDEV with the appropriate major and minor
> > device numbers? (So that reconstructing the kernel
> > modules can be avoided.)
> 
> Yes. Just place appropriate mknod somewhere - probably beginning of
> /etc/init.d/vmware is best place for them.

That's a fine solution.  I understand the vmware developer's position
and don't have a problem with it.

thanks,

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