On Dienstag, 10. März 2009 19:43 Jan Spakula wrote:

This reminds of a problem Dusty had and discussed on forums: http://bbs.archlinux.org/viewtopic.php?id=60060 Result: the device node was created before the rule was applied.

Thanks for the information. So i can stop searching in which start script the devices get created because i have to debug it.

So maybe ... ?

I take the question mark.-)

Good luck,

No problem, the workaround is to load tun in the rc.conf and than i have the permissions what i want. See you, Attila

On Tue, Mar 10, 2009 at 1:45 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:

On Tue, Mar 10, 2009 at 12:51 PM, Attila <attila@invalid.invalid> wrote:

...

Hi,

i use a script to prepare a bridged network for a kvm session and therefore i have this line in /etc/udev/rules.d/01-attila.rules:

KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"

After upgrading udev my file permissions of the new persistent /dev/net/tun looks so after booting up:

crw-rw-rw- 1 root root 10, 200  8. Mär 00:43 /dev/net/tun

I play with this lines in /etc/udev/permissions.d/00-my.permissions:

a) tun:root:network:0660 b) net/tun:root:network:0660

I reboot even after changing the line but there is no change. If i do a "modprobe tun" there be the right permissions:

crw-rw---- 1 root network 10, 200  8. Mär 00:43 /dev/net/tun

So my questions is how and/or where can i control the file permissions of the persistent devices from the new udev?

This is definitly not bad, i want more to know what i have overseen.-)

tun and a few other devices (loopX) are created statically in /lib/udev/devices/ and then placed on top of /dev/ when udev starts up. You can modify the initial permissions of these devices there

If the default group of some of these devices should be changed (looks like tun should be in the network group by default), please file a bug report

Attila schrieb:

...

If the default group of some of these devices should be changed (looks like tun should be in the network group by default), please file a bug report

Oh, i don't know if tun should have this permissions or if the file mask 666 is needed from another application. Until udev-139 this was my way and that is the reason why i recognized it.

In /lib/udev/devices, I simply replicated the default udev rule from 139 (which says root:root, 0666). The permissions of /dev/net/tun do not matter at all. If you access the device, you will only be able to use those interfaces that you own. Creating interfaces and setting the owner requires privileges. For example, if you run tunctl -u attila -t tap0 the only users that can access the tap0 device are attila and root. The kernel checks the permissions separately and independently of the permissions of the special file.

I'm only wondering that nothing from rules.d or permissions.d is used for creating this device. The loop devices at example has the same permissions as in /etc/udev/permissions.d/udev.permissions.

These devices are simply copied in rc.sysinit line 23: /bin/cp -a /lib/udev/devices/* /dev/ udev rules are not applied until the module is loaded and a uevent for creating the device is issued, then udev reads the rule(s) and acts accordingly.

Attila schrieb:

...

These devices are simply copied in rc.sysinit line 23: /bin/cp -a /lib/udev/devices/* /dev/ udev rules are not applied until the module is loaded and a uevent for creating the device is issued, then udev reads the rule(s) and acts accordingly.

The funny thing what i recognized too as i looks more in /lib/udev/devices is that there the loop devices has "root:root, 0666" but in my /dev they have "root:disk, 0660". The reason seams that because i use my own kernel package with "CONFIG_BLK_DEV_LOOP=y" instead of "CONFIG_BLK_DEV_LOOP=m".

I have root:disk in /lib/udev/devices/loop/ and in /dev/loop/. I am thinking about creating only /dev/loop/0 and /dev/loop0, as that is the only one needed: Once you access the first loop device, the module is loaded and more are created. But then, that can wait until the next release.

But again, i was only wondering not afraid about it.-) And to say something good at the end about the last updates: Thanks a lot for activating VIRTIO in kernel26.

Not my work, but you're welcome.

Aaron Griffin schrieb:

tun and a few other devices (loopX) are created statically in /lib/udev/devices/ and then placed on top of /dev/ when udev starts up. You can modify the initial permissions of these devices there

How does pacman handle this on updates? Does it prefer the mode of the on-disk file or revert it to the package value?

Allan McRae schrieb:

Files are removed then the new one extracted, so you should end up with the package permissions. Shared directories are more interesting... (you will get a warning about permission differences).

Can this be overridden with NoUpgrade or NoExtract? I would guess so.

On Dienstag, 10. März 2009 20:05 Gerardo Exequiel Pozzi wrote:

The tun dev is statically created, and the perms are adjusted in /lib/udev/rules.d/50-udev-default.rules then if you need to adjust these perms make a file >50 in /etc/udev/rules.d/ like this:

Oh, i forgot to post the whole line from my rules file and that is why i'm in hope that i can use a number <50.

[root@arch32 ~]# cat /etc/udev/rules.d/99-myperms.rules KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"

I use the same as you but append OPTIONS="last_rule" at the end of the line in my /etc/udev/rules.d/01-attila.rules: KERNEL=="tun", NAME="net/%k", MODE="0660", \ GROUP="network", OPTIONS="last_rule"

[root@arch32 ~]# ls -l /dev/net/tun crw-rw-rw- 1 root root 10, 200 2009-03-07 21:43 /dev/net/tun [root@arch32 ~]# modprobe tun [root@arch32 ~]# ls -l /dev/net/tun crw-rw---- 1 root network 10, 200 2009-03-07 21:43 /dev/net/tun

Our results be the same so i hope the numbering of the file is not the problem. See you, Attila