Bug 1139034 - /dev/snd/timer and /dev/snd/seq occasionally have their permissions changed
Summary: /dev/snd/timer and /dev/snd/seq occasionally have their permissions changed
Status: CLOSED DUPLICATE of bug 1147248
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-09-07 16:12 UTC by Bruno Wolff III
Modified: 2014-11-12 11:10 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-04 22:41:11 UTC
Type: Bug

Attachments (Terms of Use)
Update list (11.24 KB, text/plain)
2014-09-10 16:07 UTC, Bruno Wolff III
no flags Details
Output showing that systemd updates are changing the permissions (2.95 KB, text/plain)
2014-09-10 19:59 UTC, Bruno Wolff III
no flags Details
/run/tmpfiles.d/kmod.conf (652 bytes, text/plain)
2014-09-10 20:12 UTC, Bruno Wolff III
no flags Details

Description Bruno Wolff III 2014-09-07 16:12:01 UTC
Description of problem:

Every once in a while /dev/snd/timer and /dev/snd/seq change from 660 to 600 while I'm logged in, which breaks sound. I am going to start watching what happens after updates more carefully, since my first guess is that some package update does this, but I usually wouldn't notice until significantly later.

I am guessing this is systemd related because it is responsible for /dev stuff, but it could be something else. (No rpms own /dev/snd so it isn't obvious which package this should be filed against.)

How reproducible:
I am not sure how to trigger it, but it seems to happen very roughly on the order of once a week.

Comment 1 Bruno Wolff III 2014-09-08 14:04:42 UTC
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.

Comment 2 Bruno Wolff III 2014-09-10 16:07:52 UTC
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.

Comment 3 Bruno Wolff III 2014-09-10 19:59:20 UTC
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

Comment 4 Bruno Wolff III 2014-09-10 20:05:34 UTC
systemd-tmpfiles --create in the post install script seems to be the culprit.

Comment 5 Bruno Wolff III 2014-09-10 20:12:53 UTC
Created attachment 936319 [details]

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.

Comment 6 Bruno Wolff III 2014-09-10 20:37:29 UTC
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.

Comment 7 Zbigniew Jędrzejewski-Szmek 2014-09-10 23:16:23 UTC
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.

Comment 8 Tom Gundersen 2014-09-11 06:12:06 UTC
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)

Comment 9 Zbigniew Jędrzejewski-Szmek 2014-09-30 20:42:59 UTC
(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.

Comment 10 Zbigniew Jędrzejewski-Szmek 2014-10-01 15:54:29 UTC
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.

Comment 11 Richard W.M. Jones 2014-10-10 17:58:48 UTC
FWIW when I updated Fedora 20 to systemd-208-22.fc20.x86_64
today, at least two files were changed from 666 to 600:


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

Comment 12 David Woodhouse 2014-11-03 20:39:15 UTC
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.

Comment 13 Tom Gundersen 2014-11-04 16:25:30 UTC

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.

Comment 14 Zbigniew Jędrzejewski-Szmek 2014-11-04 22:41:11 UTC
OK, this should be fixed now. Please test the update.

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

Comment 15 David Woodhouse 2014-11-12 11:10:05 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.