+++ This bug was initially created as a clone of Bug #1147248 +++
Description of problem:
Bug #1084052 adds the %post command "systemd-tmpfiles --create >/dev/null 2>&1 || :" in systemd-208-21.fc20.
Unfortunately, this removes permissions in /dev during a package upgrade.
The permissions of /dev/fuse are changed from 666 to 600. As a consequence, normal users cannot use fuse anymore.
A reboot or a downgrade to systemd <= 208-20 fixes this issue.
Using
"systemd-tmpfiles --create --exclude-prefix=/dev >/dev/null 2>&1 || :"
instead of
"systemd-tmpfiles --create >/dev/null 2>&1 || :"
would fix this problem.
However, I am not sure how it would affect the original issue reported in #1084052.
Version-Release number of selected component (if applicable):
systemd-208-21.fc20
How reproducible:
Always
Steps to Reproduce:
1. yum install fuse
2. yum install systemd-208-20 (or earlier) incl. dependencies
3. ls -l /dev/fuse
4. yum install systemd-208-21 (or later) incl. dependencies
5. ls -l /dev/fuse
Actual results:
$ ls -l /dev/fuse
crw-rw-rw-. 1 root root 10, 229 Sep 28 14:18 /dev/fuse
# update systemd
$ ls -l /dev/fuse
crw-------. 1 root root 10, 229 Sep 28 14:19 /dev/fuse
Expected results:
$ ls -l /dev/fuse
crw-rw-rw-. 1 root root 10, 229 Sep 28 14:18 /dev/fuse
# update systemd
$ ls -l /dev/fuse
crw-rw-rw-. 1 root root 10, 229 Sep 28 14:19 /dev/fuse
Additional info:
--- Additional comment from Jan Synacek on 2014-10-14 10:04:04 EDT ---
On my system, /dev/fuse is present in /run/tmpfiles.d/kmod.conf. It has a 'c' flag, meaning that the file should be created only if it doesn't exist. For some reason, its mode is still set.
Fix hopefully incoming.
--- Additional comment from Jan Synacek on 2014-10-29 09:11:58 EDT ---
The fix for this problem has two parts.
First, kmod needs to be patched to properly generate the tmpfiles.d configuration. Second, systemd-tmpfiles-setup-dev.service needs to be updated to include the --boot parameter (available in systemd v217).
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024673.html
--- Additional comment from Josh Boyer on 2014-10-29 12:36:13 EDT ---
(In reply to Jan Synacek from comment #2)
> The fix for this problem has two parts.
>
> First, kmod needs to be patched to properly generate the tmpfiles.d
> configuration. Second, systemd-tmpfiles-setup-dev.service needs to be
> updated to include the --boot parameter (available in systemd v217).
>
> http://lists.freedesktop.org/archives/systemd-devel/2014-October/024673.html
Is Fedora 20 going to get systemd v217? Because if not, I don't see the point in backporting the kmod fix. And if not, then is there something systemd should revert so that F20 is actually fixed?
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-10-29 12:57:55 EDT ---
(In reply to Josh Boyer from comment #3)
> Is Fedora 20 going to get systemd v217? Because if not, I don't see the
> point in backporting the kmod fix. And if not, then is there something
> systemd should revert so that F20 is actually fixed?
F20 is not going to get systemd-217 because it's too big of a change. But it gets some backported patches, this one will be included.
--- Additional comment from Josh Boyer on 2014-10-29 13:15:15 EDT ---
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> (In reply to Josh Boyer from comment #3)
> > Is Fedora 20 going to get systemd v217? Because if not, I don't see the
> > point in backporting the kmod fix. And if not, then is there something
> > systemd should revert so that F20 is actually fixed?
> F20 is not going to get systemd-217 because it's too big of a change. But it
> gets some backported patches, this one will be included.
Do you have a timeframe? The fixed systemd and kmod packages should be bundled in the same update in Bodhi so this isn't broken/fixed piecemeal.
I can do the backport of that single patch and build it, and then perhaps just reassign this bug to systemd so those maintainers can create the bodhi update?
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-10-29 13:38:05 EDT ---
(In reply to Josh Boyer from comment #5)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> > (In reply to Josh Boyer from comment #3)
> > > Is Fedora 20 going to get systemd v217? Because if not, I don't see the
> > > point in backporting the kmod fix. And if not, then is there something
> > > systemd should revert so that F20 is actually fixed?
> > F20 is not going to get systemd-217 because it's too big of a change. But it
> > gets some backported patches, this one will be included.
>
> Do you have a timeframe?
Should be tonight.
> The fixed systemd and kmod packages should be
> bundled in the same update in Bodhi so this isn't broken/fixed piecemeal.
Yes...
> I can do the backport of that single patch and build it, and then perhaps
> just reassign this bug to systemd so those maintainers can create the bodhi
> update?
...but I can't do the update afaik, because I'm neither maintainer for kmod nor proven packager. Somebody else will have to do the update.
--- Additional comment from Josh Boyer on 2014-10-29 14:39:42 EDT ---
OK, builds complete:
F21: http://koji.fedoraproject.org/koji/buildinfo?buildID=588917
F20: http://koji.fedoraproject.org/koji/buildinfo?buildID=588919
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-10-30 01:24:31 EDT ---
So... If someone who can could create an F20 update using systemd-208-26.fc20 kmod-15-2.fc20. I guess I should apply for proven packager privileges for the next time.
Buglist: 1052262 1110712 1073830 1095962 1139694 1109478 1091513 790768 1128360 1149069 1124843 1049306 727499 1147248
Description: Bugfixes for the listed bugs plus some other small ones. kmod is updated together with systemd because of the need to coordinate changes for bug #1147248.
Request: stable
--- Additional comment from Fedora Update System on 2014-10-30 08:00:08 EDT ---
systemd-208-26.fc20,kmod-15-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-26.fc20,kmod-15-2.fc20
--- Additional comment from Josh Boyer on 2014-10-30 08:01:03 EDT ---
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> So... If someone who can could create an F20 update using
> systemd-208-26.fc20 kmod-15-2.fc20. I guess I should apply for proven
> packager privileges for the next time.
Done. What about F21?
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-10-30 09:47:29 EDT ---
(In reply to Josh Boyer from comment #10)
> Done.
Thanks.
> What about F21?
Today or tomorrow, depending on how complicated fix for #1154768 will be.
--- Additional comment from Fedora Update System on 2014-10-31 21:40:56 EDT ---
Package systemd-208-26.fc20, kmod-15-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-26.fc20 kmod-15-2.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14032/systemd-208-26.fc20,kmod-15-2.fc20
then log in and leave karma (feedback).
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-11-02 22:57:25 EST ---
(In reply to Josh Boyer from comment #10)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> > So... If someone who can could create an F20 update using
> > systemd-208-26.fc20 kmod-15-2.fc20. I guess I should apply for proven
> > packager privileges for the next time.
>
> Done. What about F21?
systemd-216-7 is building now. It has fixes for this and the other bugs that were in the queue. I also added a requirement for kmod >= 18-4.
It would be great if you (or someone) could create an update for F21.
Bugs #1154126, #727499, #1157847, #1154768, #1159641, #1158206, #1151958, and this one (#1147248).
--- Additional comment from Fedora Update System on 2014-11-03 08:24:09 EST ---
kmod-18-4.fc21,systemd-216-7.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-7.fc21
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-11-04 09:12:14 EST ---
Hi Josh,
I canceled the update yesterday because sgallagh and adamw asked me to split out one patch as a separate update to fix the upgrade images. This smaller update went stable yesterday, so this one is good to go again. If you could release it:
- kmod-18-4.fc21,systemd-216-9.fc21
- #1154126, #1157847, #1154768, #1158206, #1151958 (slightly smaller then previously, because of the split, and also because I removed one patch which is a cleanup and can wait)
Thank you for your patience!
--- Additional comment from Fedora Update System on 2014-11-04 09:21:23 EST ---
kmod-18-4.fc21,systemd-216-9.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-11-04 17:03:49 EST ---
Hi Josh,
if you could substitute systemd-216-10.fc21. It has one patch for #1159641. Sorry again for the trouble.
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-11-04 17:41:11 EST ---
--- Additional comment from Josh Boyer on 2014-11-04 18:18:47 EST ---
Do you have some text for a better update description?
--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2014-11-04 20:04:59 EST ---
(In reply to Josh Boyer from comment #19)
> Do you have some text for a better update description?
-10 only has this one patch:
- systemd-journald-flush.service hang caused a by a race with systemd-journald.service start is fixed by changing the latter to Type=notify.
As for -9:
- PackageKit.service is dropped from presets (#1154126)
- /dev/disk/by-path paths are again created for iscsi and other "well-known" scsi buses (#1157847)
- boot and shutdown timeouts remain disabled (#1154768)
- timers.target is not scheduled before basic.target to avoid a dependency loop during bootup when ntp is used (#1158206)
- Obsolete fi-latin1 Finnish keymap is dropped (#1151958)
- StartTimeout* options are ignored to avoid warnings if a patched fedup (from bug #1159292) was used in to upgrade which writes a custom /etc/systemd/system.conf to disable the start timeout.
- A mistaken assert that would cause an exception in systemd-python context manager code is removed.
- systemctl will guess the ".target" suffix when 'isolate' verb is used.
- shell completion suggestions will propose more units for 'start'/'restart' verbs.
- shell completion suggestions will be provided for 'set-default', 'get-default', 'is-system-running'.
- $NOTIFY_SOCKET is also set for control procs if NotifyAccess=all is specified in the service file.
- The mechanism with which systemctl asks for interactive authorization was changed to use the new d-bus flag for interactive authorization. Should not result in a visible change in behaviour.
- Hardware database entry is added for keys on compaq ku 0133 keyboards.
- Hardware database entry for Dell Inspiron 1520 is tweaked to avoid double keystrokes.
- Hardware database of Bluetooth companies is updated.
- A few (potential but unlikely to be hit) errors on out-of-memory conditions were fixed.
- Socket activation of systemd-journal-remote daemon is fixed.
- The --trust=all option of systemd-journal-upload works again.
- Socket symlinks now get proper SELinux labels.
- The shutdown process is quiet all the way into late shutdown.
- Compilation on hppa is fixed.
- Various man pages are updated and spelling fixes applied.
- System manager will not print status messages when passwords are being queried during boot.
- Other swap options from fstab, in addition to discard=..., will be passed to swapon. Currently none are supported, but this could be useful in the future if any are added.
- systemd-sysusers will not change the ownership and permissions on /etc/passwd and /etc/shadow when adding users (systemd-sysusers is not used by Fedora packages currently).
- Creation of a snapshot unit with an existing name will be properly refused.
- udev will not crash if an invalid log level is given on the kernel command line or in the config file.
- An error in the kernel-install script which caused it to exit with the message "Could not determine the kernel command line parameters" is fixed.
- Journal flushing was changed to by synchronous, so correct permissions are assigned to journal files, and the journal can be read by users in the systemd-journal and adm groups.
--- Additional comment from Fedora Update System on 2014-11-04 22:56:44 EST ---
systemd-208-26.fc20, kmod-15-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
--- Additional comment from Fedora Update System on 2014-11-05 08:17:24 EST ---
kmod-18-4.fc21,systemd-216-10.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-10.fc21
--- Additional comment from Michal Schmidt on 2014-11-10 14:56:05 EST ---
--- Additional comment from Fedora Update System on 2014-11-11 21:38:18 EST ---
kmod-18-4.fc21, systemd-216-11.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
--- Additional comment from David Woodhouse on 2014-11-12 13:18:29 EST ---
During a 'dnf update' today which installed systemd-216-11.fc11 and kmod-18-4.fc21:
[dwoodhou@i7 ~]$ ls -l /dev/net/tun
crw-------. 1 root root 10, 200 Nov 12 18:11 /dev/net/tun
[dwoodhou@i7 ~]$ ls -l /dev/net/tun
crw-------. 1 root root 10, 200 Nov 12 18:11 /dev/net/tun
On another system I tried installing kmod-18-4.fc21 first just in case there were ordering issues which you'd forgotten to express in the RPM dependencies, and the permissions were reset there too.
--- Additional comment from Sergio Monteiro Basto on 2014-11-13 00:49:57 EST ---
yeah , this weekend /dev/fuse appears without permissions when try run sshfs with my normal user
I had done, this as root to fix it :
chmod o+rw /dev/fuse
chmod g+rw /dev/fuse
but this happened after update systemd and other stable packages of fedora , without do a reboot and after wakeup from S3 , so a systemd update may need a reboot ? ...
--- Additional comment from Jan Synacek on 2014-11-13 01:33:18 EST ---
Did you reboot the system after the update?
--- Additional comment from David Woodhouse on 2014-11-13 06:12:13 EST ---
(In reply to Jan Synacek from comment #27)
> Did you reboot the system after the update?
No. The problem is "permissions are mangled during the upgrade". Hasn't a reboot *always* been sufficient to fix the permissions again? It's not clear what you expect to learn from your question. Do you think we might have made things *worse*, so a reboot no *longer* fixes the permissions? :)
--- Additional comment from Bruno Wolff III on 2014-11-13 10:14:08 EST ---
I haven't seen the issue crop up with /dev/snd recently. Was there just a one off fix for that or is something else going on with /dev/fuse?
--- Additional comment from Jan Synacek on 2014-11-14 02:33:24 EST ---
The fix should apply to all devices listed in /run/tmpfiles.d/kmod.conf. The fix was actually two patches (systemd and kmod) that had to be applied *both*. IIRC there was a short period of time when one of the packages was available for update but second wasn't, that shouldn't be the case anymore, though. And I'm not sure, by I think that for the changes to take full effect, you just have to reboot the machine.
--- Additional comment from David Woodhouse on 2015-01-07 06:52:51 EST ---
I just saw /dev/net/tun with permissions 0600 on two separate Fedora 20 systems after updating today. This bug doesn't seem to be fixed.
--- Additional comment from Sergio Monteiro Basto on 2015-01-07 12:00:51 EST ---
(In reply to David Woodhouse from comment #31)
> I just saw /dev/net/tun with permissions 0600 on two separate Fedora 20
> systems after updating today. This bug doesn't seem to be fixed.
Please, show us result of :
cat /run/tmpfiles.d/kmod.conf
--- Additional comment from David Woodhouse on 2015-01-07 13:11:50 EST ---
d /dev/cpu 0755 - - -
c /dev/cpu/microcode 0600 - - - 10:184
c /dev/fuse 0600 - - - 10:229
c /dev/btrfs-control 0600 - - - 10:234
c /dev/loop-control 0600 - - - 10:237
d /dev/net 0755 - - -
c /dev/net/tun 0600 - - - 10:200
c /dev/ppp 0600 - - - 108:0
c /dev/uinput 0600 - - - 10:223
c /dev/uhid 0600 - - - 10:239
d /dev/vfio 0755 - - -
c /dev/vfio/vfio 0600 - - - 10:196
c /dev/vhci 0600 - - - 10:137
c /dev/vhost-net 0600 - - - 10:238
d /dev/snd 0755 - - -
c /dev/snd/timer 0600 - - - 116:33
d /dev/snd 0755 - - -
c /dev/snd/seq 0600 - - - 116:1
--- Additional comment from Jan Synacek on 2015-02-04 08:53:31 EST ---
I tried to reproduce this on my F20 machine again and didn't manage to do so. The machine is fully updated.
# rpm -q systemd kmod
systemd-208-29.fc20.x86_64
kmod-15-2.fc20.x86_64
# cat /run/tmpfiles.d/kmod.conf
d /dev/cpu 0755 - - -
c! /dev/cpu/microcode 0600 - - - 10:184
c! /dev/fuse 0600 - - - 10:229
c! /dev/btrfs-control 0600 - - - 10:234
c! /dev/loop-control 0600 - - - 10:237
d /dev/net 0755 - - -
c! /dev/net/tun 0600 - - - 10:200
c! /dev/ppp 0600 - - - 108:0
c! /dev/uinput 0600 - - - 10:223
c! /dev/uhid 0600 - - - 10:239
d /dev/vfio 0755 - - -
c! /dev/vfio/vfio 0600 - - - 10:196
c! /dev/vhci 0600 - - - 10:137
c! /dev/vhost-net 0600 - - - 10:238
d /dev/snd 0755 - - -
c! /dev/snd/timer 0600 - - - 116:33
d /dev/snd 0755 - - -
c! /dev/snd/seq 0600 - - - 116:1
c! /dev/cuse 0600 - - - 10:203
# ll /dev/fuse
crw-rw-rw-. 1 root root 10, 229 Feb 4 14:42 /dev/fuse
# systemd-tmpfiles --create
# ll /dev/fuse
crw-rw-rw-. 1 root root 10, 229 Feb 4 14:42 /dev/fuse