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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).