Bug 1139034

This (the changed permissions) is also happening on a machine running F21 with rawhide nodebug kernels. However on this machine this doesn't affect sound. This machine uses motherboard sound with speaker output connected to head phones. The machine with broken sound uses USB head phones.

Created attachment 936230 [details]
Update list

The permissions apear to have changed during one of these two yum invokations. My guess it was the one doing updates rather than the one doing installs. This did include an update to systemd. I'll need to do some specific testing to narrow down the package that causes the problem.

Created attachment 936318 [details]
Output showing that systemd updates are changing the permissions

systemd updates are changing the permissions and breaking sound for some devices. You can run the following to see this:
chmod 660 /dev/snd/seq /dev/snd/timer;ls -l /dev/snd;yum reinstall -y systemd;ls -l /dev/snd

systemd-tmpfiles --create in the post install script seems to be the culprit.

Created attachment 936319 [details]
/run/tmpfiles.d/kmod.conf

There is configuration in /run/tmpfiles.d/kmod.conf which specifies the problem permissions for seq and timer (but not for other sound files). I am not sure what defines this though, as stuff in /run is volatile.

So the reason that just seq and timer show up and the others don't, is that they are listed in modules.devname.

It looks like for the c function a permission will always be set, so that the permission probably can't be left unspecified. Maybe ! could be used to only do these at boot, but it might not handle some cases were /run got messed up.

It seems odd that when you don't use a + and the file exists that the permissions still get reset.

This seems to be tough nut to crack. The file is created by kmod-static-nodes.service. It seems that in this case it would be beneficial to not set the permisssions when the file exists, as you say, but there are other cases where we explicitly rely on the updating of permissions on pre-existing files. I'm not sure what the solution here is.

Hm, why is systemd-tmpfiles --create being called on upgrade? This sounds wrong to me, at least it should be restricted to applying specific .conf fragments. In general it is not safe to call --create at run-time (there are other examples in addition to this afair)

(In reply to Tom Gundersen from comment #8)
> Hm, why is systemd-tmpfiles --create being called on upgrade?
tmpfiles snippets are supposed to be safe to call at runtime. The rules that are not safe are prefixed with ! and are only executed when tmpfiles is called with --boot.

Looking at this again, I think that adding another qualifier would be useful.
"-" could mean "do not apply permissions if the file/device/pipe/... exists". This would mirror "+" that Lennart added recently.

Looking at #1147910, Kay wants udev to be in complete charge of permissions of device in /dev. This makes sense. So I think that the correct thing is to simply not touch any device files in systemd-tmpfiles, apart from the moment of creation. When creating them, we need to set /some/ permissions, so the current behaviour on creation seems correct.

FWIW when I updated Fedora 20 to systemd-208-22.fc20.x86_64
today, at least two files were changed from 666 to 600:

/dev/net/tun
/dev/fuse

Both appear in my /run/tmpfiles.d/kmod.conf file, with (I believe)
incorrect permissions in that file.

In the case of /dev/net/tun there's absolutely no reason for it *ever* to be created with those wrong permissions. This isn't just a question whether they should be 'reset' and at what time... 0600 for /dev/net/tun is just plain wrong. At the very least, please set that back to 0666 before contemplating any other changes.

David,

Static device nodes are always created with permissions 0600, as they are created entirely based on the information the kernel has exposed (via MODULE_ALIAS) in modules.devname, and that does not contain any default permission information.

It is then up to udev to change the permissions to something more sensible. If the kernel were to expose the default permission infromation we could set it to that from the get-go, but that would require some kernel changes.

OK, this should be fixed now. Please test the update.

*** This bug has been marked as a duplicate of bug 1147248 ***

(In reply to Tom Gundersen from comment #13)
> David,
> 
> Static device nodes are always created with permissions 0600, as they are
> created entirely based on the information the kernel has exposed

Like Richard (see comment #11) I also have /run/tmpfiles.d/kmod.conf which explicitly lists (wrong) permissions for /dev/net/tun. Perhaps that's a red herring though? I'm not sure where that file comes from.

I went to log into my VPN today and /dev/net/tun has *again* been corrupted to have the wrong permissions so it failed. I have systemd-216-10.fc21.