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:
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.
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
(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?
(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.
(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?
(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.
OK, builds complete: F21: http://koji.fedoraproject.org/koji/buildinfo?buildID=588917 F20: http://koji.fedoraproject.org/koji/buildinfo?buildID=588919
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
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
(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?
(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.
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).
(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).
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
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!
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
Hi Josh, if you could substitute systemd-216-10.fc21. It has one patch for #1159641. Sorry again for the trouble.
*** Bug 1139034 has been marked as a duplicate of this bug. ***
Do you have some text for a better update description?
(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.
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.
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
*** Bug 1149418 has been marked as a duplicate of this bug. ***
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.
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.
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 ? ...
Did you reboot the system after the update?
(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? :)
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?
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.
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.
(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
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
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