Bug 790522 - Private /tmp are broken
Summary: Private /tmp are broken
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH RejectedBlocker
Keywords:
: 788061 789587 790042 (view as bug list)
Depends On:
Blocks: F17Alpha-accepted, F17AlphaFreezeExcept PrivateTmp
TreeView+ depends on / blocked
 
Reported: 2012-02-14 18:36 UTC by Simo Sorce
Modified: 2012-02-28 08:58 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-02-21 02:22:04 UTC


Attachments (Terms of Use)

Description Simo Sorce 2012-02-14 18:36:13 UTC
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 18:44:37 UTC
*** Bug 789587 has been marked as a duplicate of this bug. ***

Comment 2 Stephen Gallagher 2012-02-15 15:24:32 UTC
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 15:42:16 UTC
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 15:57:58 UTC
(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 17:51:29 UTC
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 18:13:36 UTC
(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 18:15:26 UTC
Sorry, ypserv/ypbind and dhcpd were closed NOTABUG, not RAWHIDE.

Comment 8 Dennis Gilmore 2012-02-15 20:33:54 UTC
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 20:40:11 UTC
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 20:44:24 UTC
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 20:52:37 UTC
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 20:54:20 UTC
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 20:55:59 UTC
(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 20:57:51 UTC
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 21:05:10 UTC
Yes it's part of the systemd 43 build I just referenced (and tested)

Comment 16 Adam Williamson 2012-02-15 21:15:29 UTC
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 21:25:57 UTC
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 21:42:00 UTC
-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-16 01:58:18 UTC
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-16 02:03:16 UTC
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 17:20:52 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 22 Adam Williamson 2012-02-17 17:25:09 UTC
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-21 02:22:04 UTC
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 20:20:09 UTC
*** Bug 788061 has been marked as a duplicate of this bug. ***

Comment 25 Michal Schmidt 2012-02-27 09:11:01 UTC
Fixed in F16 as well:
https://admin.fedoraproject.org/updates/systemd-37-14.fc16

Comment 26 Nicolas Mailhot 2012-02-28 08:58:51 UTC
*** 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.