Bug 790522 - Private /tmp are broken
Private /tmp are broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
:
: 788061 789587 790042 (view as bug list)
Depends On:
Blocks: F17Alpha-accepted/F17AlphaFreezeExcept PrivateTmp
  Show dependency treegraph
 
Reported: 2012-02-14 13:36 EST by Simo Sorce
Modified: 2012-02-28 03:58 EST (History)
12 users (show)

See Also:
Fixed In Version: systemd-43-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-20 21:22:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Simo Sorce 2012-02-14 13:36:13 EST
When systemd creates a private tmp the permissions on the private tmp directory seem to be wrong.

Looking at httpd's private tmp on my system I see that /tmp/systemd-namespace-<random>/private is owned by root.root and has permissions 1755 instead of 1777.
This breaks any process that switch to an unprivileged user (httpd -> apache.apache) and wnats to create temporary files.

Also when restarting the httpd.service the old private tmp is not reused nor removed and is leaked on the file system.

Reusing the old tmp would be prefereable as otherwise any temporary file being in use will be lost on apache restart.
Comment 1 Michal Schmidt 2012-02-14 13:44:37 EST
*** Bug 789587 has been marked as a duplicate of this bug. ***
Comment 2 Stephen Gallagher 2012-02-15 10:24:32 EST
Proposing for alpha blocker status. Due to this systemd bug, no service that runs as non-root and requires access to tmp files will work (apache being a notable example).
Comment 3 Jóhann B. Guðmundsson 2012-02-15 10:42:16 EST
Which criteria is this breaking?

I cant see this anymore then NTH for alpha and a blocker for beta
Comment 4 Stephen Gallagher 2012-02-15 10:57:58 EST
(In reply to comment #3)
> Which criteria is this breaking?
> 
> I cant see this anymore then NTH for alpha and a blocker for beta

Sorry, you are correct. I was incorrectly assuming httpd was considered CRITPATH, but it is not. So I agree with your assessment of NTH for alpha and blocker for beta.
Comment 5 Adam Williamson 2012-02-15 12:51:29 EST
what else is known to use private /tmp ?

For cases like httpd this can be fixed fine with an update, so I'm not sure even NTH makes a lot of sense unless there's a case you're going to hit during install or in a live boot.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Stephen Gallagher 2012-02-15 13:13:36 EST
(In reply to comment #5)
> what else is known to use private /tmp ?

See https://bugzilla.redhat.com/showdependencytree.cgi?id=782466&hide_resolved=0
(not a short list)

I'm a bit concerned that ypbind/ypserv could impact NIS logins on F17. dhcpd, cups and dovecot seem pretty serious too.
Comment 7 Stephen Gallagher 2012-02-15 13:15:26 EST
Sorry, ypserv/ypbind and dhcpd were closed NOTABUG, not RAWHIDE.
Comment 8 Dennis Gilmore 2012-02-15 15:33:54 EST
my vote here would be -1 blocker, none of this seems to prevent install or login post install and can be fixed by updates after.
Comment 9 Adam Williamson 2012-02-15 15:40:11 EST
cups and dovecot are too high-level functionality to conceivably impact alpha. I can't really see any package CLOSED RAWHIDE (implying it was implemented) that might constitute a blocker, though a couple may be NTH-worthy (ntpd, openvpn, bind maybe).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Adam Williamson 2012-02-15 15:44:24 EST
ntpd runs as a non-privileged user, so it's probably hit by this. cupsd runs as root, so it probably isn't. not sure about the others.
Comment 11 Adam Williamson 2012-02-15 15:52:37 EST
ah, ntpd is no longer default, chronyd is. so ntpd isn't too worrying. chronyd doesn't use private /tmp.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Nicolas Mailhot 2012-02-15 15:54:20 EST
The fix is available here
http://koji.fedoraproject.org/koji/buildinfo?buildID=299664

IMHO it would be safer to pull it than to try to guess which package may try to write in a private tmp and fail with strange side effects because of this bug
Comment 13 Nicolas Mailhot 2012-02-15 15:55:59 EST
(In reply to comment #12)
> The fix is available here

(at least for the can not write in private tmp part, it works with clamav and httpd)
Comment 14 Adam Williamson 2012-02-15 15:57:51 EST
http://cgit.freedesktop.org/systemd/systemd/commit/?id=21d279cf543c82705a5b3362818805603d2ab9f2 looks an awful lot like a fix.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Nicolas Mailhot 2012-02-15 16:05:10 EST
Yes it's part of the systemd 43 build I just referenced (and tested)
Comment 16 Adam Williamson 2012-02-15 16:15:29 EST
well, I just tried systemd-43, and I'm not sure it's fixed. I installed it at 13:09 and rebooted, new boot happened at 13:11, and I have:

drwx------. 4 root root 4096 Feb 15 13:11 /tmp/systemd-namespace-gmEreP

note the creation date.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Fedora Update System 2012-02-15 16:25:57 EST
systemd-43-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-43-1.fc17
Comment 18 Jóhann B. Guðmundsson 2012-02-15 16:42:00 EST
-1 to blocker -1 to nth this should just be fixed via update +1 to beta blocker if still present at that time...
Comment 19 Fedora Update System 2012-02-15 20:58:18 EST
Package systemd-43-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-43-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1780/systemd-43-1.fc17
then log in and leave karma (feedback).
Comment 20 Adam Williamson 2012-02-15 21:03:16 EST
actually, I was looking at the wrong dir - it's /tmp/systemd-namespace-blah/private/ that matters, apparently.

so looking at that, I confirm the fix. the /private dirs created *before* the update on my system are drwxr-xr-t . the /private dir created *after* the update is drwxrwxrwt . I see the same in a VM running RC2. So looks like the fix is good in RC2. Update still has to be pushed stable.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Adam Williamson 2012-02-17 12:20:52 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 22 Adam Williamson 2012-02-17 12:25:09 EST
Discussed at 2012-02-17 blocker review meeting. Agreed we can't declare this a blocker as we have no evidence that it actually causes any major issues, but accepted as NTH due to its obvious potential to cause problems and the fact that it can't entirely be fixed with an update (private /tmps created before the update is installed will retain incorrect permissions).

Note the fix was already pulled into RC2 anyway.
Comment 23 Fedora Update System 2012-02-20 21:22:04 EST
systemd-43-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Nicolas Mailhot 2012-02-23 15:20:09 EST
*** Bug 788061 has been marked as a duplicate of this bug. ***
Comment 25 Michal Schmidt 2012-02-27 04:11:01 EST
Fixed in F16 as well:
https://admin.fedoraproject.org/updates/systemd-37-14.fc16
Comment 26 Nicolas Mailhot 2012-02-28 03:58:51 EST
*** Bug 790042 has been marked as a duplicate of this bug. ***

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