Created attachment 573350 [details] The log.txt file contains the commands that were run to trace the point at which the permissions of the /tmp directory gets changed . See at the end ot the log.txt file. Description of problem: Recently we observed in Fedora-16 that while installing/updating the cups-libs package using “yum install –y cups-libs” we see that permissions of /tmp directory is getting changed from “drwxrwxrwt” to “drwxr-xr-t” . Because of which non-root users are unable to create files in the /tmp directory and also after rebooting the system unable to login. Please find the attached log files while installing cups-libs Version-Release number of selected component (if applicable): cups-libs-1.5.2-6.fc16.i686.rpm (http://mirror.symnds.com/distributions/fedora/updates/16/i386/) How reproducible: 1.Install a clean image of the Fedora-16 i686. 2.Run command "yum install cups-libs" or "yum update cups-libs" Steps to Reproduce: 1.Install a clean image of the Fedora-16 i686. 2.Check the permissions of the /tmp directory by command : ls -l / | grep tmp it will be "drwxrwxrwt" 3.Run command "yum install cups-libs" or "yum update cups-libs" 4.Check the permissions of the /tmp directory by command : ls -l / | grep tmp it will be "drwxr-xr-t" Actual results: /tmp directory permissions are changed to "drwxr-xr-t" Expected results: /tmp directory permissions should remain same to "drwxrwxrwt" Additional info: The update cups-libs-1.5.2-6.fc16.i686.rpm was recently added in the fedora update repository on 17th march 2012.
Hello Goutam, are you able to reproduce the problem (or did it happen only once) ? I'm not able to reproduce this on Fedora-17 when updating from 1.5.0-16.fc17.x86_64 to 1.5.2-6.fc17.x86_64. The only tmp related change that I see in changelog is * Tue Jan 17 2012 Tim Waugh 1:1.5.0-27 - Use PrivateTmp=true in the service file (bug #782495).
Hmm, could be bug #790522. Please update systemd to version 37-14.fc16 or later.
cups-1.5.2-8.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/cups-1.5.2-8.fc17
cups-1.5.2-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/cups-1.5.2-8.fc16
Thanks for the report. The cause was a bug in a systemd feature (PrivateTmp) which had been enabled in the most recent cups update. Although a newer version of systemd has been made available, this fixed version is not listed as a dependency of the cups package. Please try with the above test update, when it becomes available, as follows: 1. Install Fedora 16. 2. yum --enablerepo=updates-testing update cups-libs It should take no more than 3-4 days. You can test earlier than that by downloading the cups packages directly and following this procedure: 1. Install Fedora 16 2. Download the cups packages from the test update page 3. yum update ./cups-libs-1.5.2-8.fc16.*.rpm ./cups-1.5.2-8.fc16.*.rpm
Thanks All, for looking into the issue and letting us know on what caused this issue. Will test the with the latest update and let you know on the same
F16 x86_64: systemd-37-17 + cups-1.5.2-8: /tmp permissions are ok but umount (usb and other removable media) still fails. interesting: when booted with cups enabled but stopping cups before mounting the removable media then umount will work OK (cups must not be running while removable media is mounted) update: it is enough to stop cups before mounting and before unmounting. starting it again while removable media is mounted does not harm as long as it is stopped before umount. now I am getting really curious.. This bug can cause data loss - I have just been lucky watching the LED of my esata drive and seeing activity for several seconds caused by a manual sync after umount made me curious. see also BZ 747114 and 806909
OK, I think the best solution is to remove PrivateTmp from cups in F-16 then.
cups.service: setting PrivateTmp to false and all works OK. Tim, could you please drop one or two lines about the root cause (if you know:-) so we (I) can learn. Thanks, Konrad
I don't think the root cause is yet known, but is something to do with the implementation of PrivateTmp support in systemd. The PrivateTmp line in the cups.service file was intended for Fedora 17 but ended up in Fedora 16 as well, not entirely intentionally.
Thanks, Tim! ...now starting to read about mount namespaces. (http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html) still wondering that nothing unusual showed up in findmnt. -k
Package cups-1.5.2-8.1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-1.5.2-8.1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5005/cups-1.5.2-8.1.fc16 then log in and leave karma (feedback).
When can cups-1.5.2-8.1.fc16 & cups-libs-1.5.2-8.fc16 packages will be available in the main update repository of fedora 16 ? We have a automated installation system which try to install the packages cups & cups-libs from main repository of fedora 16 and it picks up version 1.5.2-6. If we can have cups-1.5.2-8.1.fc16 & cups-libs-1.5.2-8.fc16 in the main repository of Fedora 16 at the earliest it would easier our efforts in installing these packages. Thanks for your support and quick updates. Regards, Goutam Kodu
It needs testing first. I haven't yet had confirmation from anyone that it fixes both this problem and the one described in bug #808109.
Hi Tim, We tested as per the instructions provided in comment 12 and we could not reproduce the issue. Seems like this has got fixed in cups-1.5.2-8.1.fc1 package. Will wait for its upload in the main repository. Thanks, Goutam kodu
Goutam: thanks for testing. Yes, *this* bug is believed to be fixed; but bug #808109 is still outstanding and is just as serious.
cups-1.5.2-8.1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 811456 has been marked as a duplicate of this bug. ***
cups-1.5.2-10.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
I'm trying to install hplip-3.12.4-4 (so this seems like the place to create a post) on Centos 6.4 where yum is quite broken, causing the automatic script to fail. Taking a manual approach, using RPM to install these RPMs... hplip-3.12.4-4.el6.x86_64.rpm hplip-gui-3.12.4-4.el6.x86_64.rpm PyQt4-4.6.2-9.el6.x86_64.rpm python-imaging-1.1.6-19.el6.x86_64.rpm python-reportlab-2.3-3.el6.x86_64.rpm sip-4.9.3-1.el6.x86_64.rpm using: rpm -i --force *.rpm the last five RPMs install, but hplip doesn't, emitting the following errors: warning: hplip-3.12.4-4.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY error: error creating temporary file /var/tmp/rpm-tmp.u9KrZq: Invalid argument error: Couldn't create temporary file for %pre(hplip-3.12.4-4.el6.x86_64): Invalid argument error: install: %pre scriptlet failed (2), skipping hplip-3.12.4-4.el6 error: error creating temporary file /var/tmp/rpm-tmp.emh8Ny: Invalid argument error: Couldn't create temporary file for %post(hplip-gui-3.12.4-4.el6.x86_64): Invalid argument Any suggestions?
(In reply to Mike Landis from comment #20) > I'm trying to install hplip-3.12.4-4 (so this seems like the place to create > a post) on Centos 6.4 No, this is not the place. This is a bug tracker, not a forum. And this is a bug tracker for Fedora and RHEL - not for CentOS.
(In reply to Mike Landis from comment #20) > warning: hplip-3.12.4-4.el6.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID > c105b9de: NOKEY > error: error creating temporary file /var/tmp/rpm-tmp.u9KrZq: Invalid > argument > error: Couldn't create temporary file for %pre(hplip-3.12.4-4.el6.x86_64): > %post(hplip-gui-3.12.4-4.el6.x86_64): Invalid argument I'm not sure what's cause of these errors, but I don't think it's hplip. We don't create any temporary files in hplip's %pre or hplip-gui's %post. I'd start with filling a bug against rpm. > I'm trying to install hplip-3.12.4-4 (so this seems like the place to create > a post) on Centos 6.4 Try http://bugs.centos.org > where yum is quite broken, causing the automatic script to fail. That could be somehow related. I'd fill a bug against yum or rpm.