From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: permissions: udev vs. pam_devperm.so
Date: Wed, 27 Oct 2004 00:02:32 +0000 [thread overview]
Message-ID: <20041027000232.GA3221@vrfy.org> (raw)
In-Reply-To: <417DF0A8.2060108@bio.ifi.lmu.de>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
On Tue, Oct 26, 2004 at 03:20:40PM +0200, Frank Steiner wrote:
> Kay Sievers wrote
>
> >Empty fields mean default permissions, so this will not work. udev will
> >overwrite everything on "add". Only the inode may be preserved, if the
> >node already exists with the correct major/minor.
>
> Just one comment:
> Having "hdc*:root:disk:660" in udev.permissions and calling "udevstart"
> will always set /dev/hdc to root:disk and 600. With owner and group
> fields empty, udevstart will not change the owner and the group. I'm
> not sure if udevstart triggers "add" events, likely not?
Sure, udevstart simulates a "add" event for every device it can find. I
can't reproduce the failure. I expect you have a earlier line matching in
one of your .permissions files.
udev searches the list from the top and the first match will make it. Do
you have "hd*:..." or similar before the "hdc*"?
> With the permission field empty, udevstart will set the permissions
> to 000, although udev.conf specifies 0600 as default, so I guess this
> is wrong...
Yes, it is wrong. We only apply the defaults if we don't match any rule.
The attached patch should fix this.
Thanks,
Kay
[-- Attachment #2: udev-apply-default-perms-01.patch --]
[-- Type: text/plain, Size: 1069 bytes --]
===== namedev.c 1.154 vs edited =====
--- 1.154/namedev.c 2004-10-20 03:59:11 +02:00
+++ edited/namedev.c 2004-10-27 01:46:02 +02:00
@@ -798,11 +798,10 @@
set_empty_perms(udev, perm->mode,
perm->owner,
perm->group);
- } else {
- set_empty_perms(udev, get_default_mode(),
- get_default_owner(),
- get_default_group());
}
+ set_empty_perms(udev, get_default_mode(),
+ get_default_owner(),
+ get_default_group());
dbg("name, '%s' is going to have owner='%s', group='%s', mode = %#o",
udev->name, udev->owner, udev->group, udev->mode);
===== test/udev-test.pl 1.60 vs edited =====
--- 1.60/test/udev-test.pl 2004-10-18 15:17:42 +02:00
+++ edited/test/udev-test.pl 2004-10-27 01:50:06 +02:00
@@ -550,11 +550,11 @@
EOF
},
{
- desc => "permissions tty3:::",
+ desc => "permissions tty3::: (default mode applied)",
subsys => "tty",
devpath => "/class/tty/tty3",
exp_name => "tty3",
- exp_perms => "0:0:0",
+ exp_perms => "0:0:600",
conf => <<EOF
KERNEL="tty3", NAME="tty3"
EOF
next prev parent reply other threads:[~2004-10-27 0:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 6:37 permissions: udev vs. pam_devperm.so Frank Steiner
2004-10-26 12:25 ` Kay Sievers
2004-10-26 12:30 ` Frank Steiner
2004-10-26 13:16 ` Kay Sievers
2004-10-26 13:20 ` Frank Steiner
2004-10-26 13:49 ` Frank Steiner
2004-10-26 14:47 ` Kay Sievers
2004-10-26 14:57 ` Kay Sievers
2004-10-27 0:02 ` Kay Sievers [this message]
2004-10-27 5:59 ` Frank Steiner
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=20041027000232.GA3221@vrfy.org \
--to=kay.sievers@vrfy.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.