|Summary:||[f23 - atomic] 755 perms on /tmp directory (symlink to /sysroot/tmp)|
|Product:||[Fedora] Fedora||Reporter:||Dusty Mabe <dustymabe>|
|Component:||ostree||Assignee:||Colin Walters <walters>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||23||CC:||acarter, kparal, mattdm, mbarnes, mruckman, pbrobinson, walters|
|Target Milestone:||---||Keywords:||CommonBugs, Reopened|
|Fixed In Version:||ostree-2015.9-2.fc23 ostree-2015.9-3.fc23||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-11-19 09:53:31 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Dusty Mabe 2015-10-30 20:41:25 UTC
Description of problem: The permissions of the /tmp dir on F23 atomic host RC10 are 755 when they should be 777. This breaks things that want to write to tmp but dont't have permissions to: ``` -bash-4.3# stat /tmp File: ‘/tmp’ -> ‘sysroot/tmp’ Size: 11 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 4340854 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:tmp_t:s0 Access: 2015-10-30 02:06:17.653254945 +0000 Modify: 2015-10-30 02:05:32.377201005 +0000 Change: 2015-10-30 02:05:32.377201005 +0000 Birth: - -bash-4.3# stat -L /tmp File: ‘/tmp’ Size: 171 Blocks: 0 IO Block: 4096 directory Device: fd00h/64768d Inode: 101 Links: 7 Access: (1755/drwxr-xr-t) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:tmp_t:s0 Access: 2015-10-30 20:32:06.579000000 +0000 Modify: 2015-10-30 20:32:28.518000000 +0000 Change: 2015-10-30 20:32:28.518000000 +0000 Birth: - -bash-4.3# stat /sysroot/tmp/ File: ‘/sysroot/tmp/’ Size: 171 Blocks: 0 IO Block: 4096 directory Device: fd00h/64768d Inode: 101 Links: 7 Access: (1755/drwxr-xr-t) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:tmp_t:s0 Access: 2015-10-30 20:32:06.579000000 +0000 Modify: 2015-10-30 20:38:55.243000000 +0000 Change: 2015-10-30 20:38:55.243000000 +0000 Birth: - ``` Version-Release number of selected component (if applicable): cloud image from: http://dl.fedoraproject.org/pub/alt/stage/23_RC10/Cloud_Images/x86_64/Images/ -bash-4.3# rpm-ostree status TIMESTAMP (UTC) VERSIONID OSNAME REFSPEC * 2015-10-29 03:54:57 23 f85f5e7bfc fedora-atomic fedora-atomic:fedora-atomic/f23/x86_64/docker-host
Comment 1 Colin Walters 2015-10-30 21:03:48 UTC
That's pretty bad. This looks like a bug in libgsystem (or ostree's use of libgsystem). I'm not sure why it didn't break in F22, this code dates to 2012. Oh...I bet this is a tmp-on-tmpfs issue. Use of tmpfs would have masked this.
Comment 2 Dusty Mabe 2015-10-30 21:06:55 UTC
(In reply to Colin Walters from comment #1) > That's pretty bad. This looks like a bug in libgsystem (or ostree's use of > libgsystem). I'm not sure why it didn't break in F22, this code dates to > 2012. > > Oh...I bet this is a tmp-on-tmpfs issue. Use of tmpfs would have masked > this. Yeah I'm not sure. Did we stop using tmpfs for /tmp in 23? If we get this fixed in ostree then maybe we could have it ready in time for the first 2 week atomic release?
Comment 3 Fedora Blocker Bugs Application 2015-10-30 21:06:56 UTC
Proposed as a Blocker for 23-final by Fedora user walters using the blocker tracking app because: Having a working /tmp is pretty important, though the workaround is pretty easy, just `chmod 1777 /sysroot/tmp`.
Comment 4 Dusty Mabe 2015-10-30 21:10:19 UTC
(In reply to Fedora Blocker Bugs Application from comment #3) > Proposed as a Blocker for 23-final by Fedora user walters using the blocker > tracking app because: > Too late for that. The primary reason I wrote up the bug report is so we could list it as a "common bug". There is no room left for blockers as we have chosen to go forward with releasing RC10 already.
Comment 5 Colin Walters 2015-10-30 21:15:35 UTC
I'm not really sure it makes sense to release the F23 Atomic Host with this.
Comment 6 Dusty Mabe 2015-10-30 21:19:59 UTC
Containers still run. If they didn't then I would be more concerned. As you also stated it is a simple workaround. Since this image will only be featured for 2 weeks then I think it's not that bad to release it so that we do have something on release day and we can cover the marketing channels and such. We could also take it to the mailing list to get more opinions.
Comment 7 Fedora Update System 2015-10-30 22:08:27 UTC
ostree-2015.9-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd4760d0fc
Comment 8 Mike Ruckman 2015-10-30 22:47:41 UTC
Additionally, this can't be a blocker because it only affects Atomic (aiui). However, I did update the CommonBugs page with this workaround.
Comment 9 Fedora Update System 2015-11-01 06:56:27 UTC
ostree-2015.9-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update ostree' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd4760d0fc
Comment 10 Colin Walters 2015-11-01 21:06:01 UTC
Note the installation media (anaconda/lorax) has to be regenerated with this, then the cloud images have to use the updated installer. Alternatively...we could likely fix this in %post in the kickstart too.
Comment 11 Colin Walters 2015-11-03 20:50:58 UTC
I'll investigate writing a systemd unit file for this.
Comment 12 Fedora Update System 2015-11-04 20:52:14 UTC
ostree-2015.9-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Dusty Mabe 2015-11-05 15:11:32 UTC
should we re-open and close once the systemd unit is in place?
Comment 14 Dusty Mabe 2015-11-06 16:03:02 UTC
re-opening to track creation of systemd unit for acarter
Comment 15 Matthew Barnes 2015-11-12 15:27:58 UTC
Created attachment 1093365 [details] ostree.spec patch This adds a systemd unit to set permissions on /tmp. It needs peer-review, particularly on where in the boot sequence it should fall. I just went with "DefaultDependencies=yes" because my own dependency guesswork wasn't working, but I suspect it needs to execute earlier.
Comment 16 Colin Walters 2015-11-12 15:53:39 UTC
Comment on attachment 1093365 [details] ostree.spec patch Too bad there's not a `ConditionMode`, then we could have the service only trigger when necessary. We need to also have this service enabled, so I'd add it to 91-ostree.preset as well. And we'll want an `[Install]` section so that works. That leads to the question of where it is in the bootup. DefaultDependencies=yes would imply we just want the typical: WantedBy=multi-user.target But I think we need to run before basically any non-root service that might want to write into /tmp. I'm going to say we should use: DefaultDependencies=no After=systemd-tmpfiles-setup.service Before=local-fs.target Or maybe just Before=sysinit.target See `man bootup` for some more information on this.
Comment 17 Colin Walters 2015-11-12 16:09:26 UTC
Or alternatively...`ostree-remount.service` (ostree-remount.c) is already running in this area, and it's kind of related... where we could just add the chmod to ostree-remount.c ?
Comment 18 Matthew Barnes 2015-11-13 15:06:24 UTC
Created attachment 1093695 [details] Patch ostree-remount.c I agree patching an existing systemd unit is easier for something this trivial. How's this? Also, does this need to go upstream or is it just a transient issue for F23?
Comment 19 Matthew Barnes 2015-11-13 15:09:02 UTC
(In reply to Matthew Barnes from comment #18) > Created attachment 1093695 [details] > Patch ostree-remount.c (I updated the changelog blurb already but forgot to include it in the patch.)
Comment 20 Dusty Mabe 2015-11-13 15:12:08 UTC
(In reply to Matthew Barnes from comment #18) > Also, does this need to go upstream or is it just a transient issue for F23? I would say it only needs to be there for F23. This shouldn't be a problem in the future since the cause of the issue got fixed.
Comment 21 Colin Walters 2015-11-13 15:18:35 UTC
LGTM. Did you test it?
Comment 22 Colin Walters 2015-11-16 15:32:48 UTC
Comment 23 Matthew Barnes 2015-11-16 16:16:22 UTC
(In reply to Colin Walters from comment #21) > LGTM. Did you test it? My /sysroot/tmp dir was set correctly to begin with, but systemd shows ostree-remount.service ran and exited successfully with the patch. I also manually changed the directory perms before reboot and it's world-writable now, but I'm not sure if that change sticks even without the patch. So AFAICT the patch is working.
Comment 24 Fedora Update System 2015-11-16 16:23:53 UTC
ostree-2015.9-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-5f8e9e7d20
Comment 25 Fedora Update System 2015-11-18 16:53:01 UTC
ostree-2015.9-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update ostree' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-5f8e9e7d20
Comment 26 Dusty Mabe 2015-11-18 17:31:42 UTC
The name of your git commit  is misleading. It doesn't appear that there is any new systemd unit (ostree-tmp-chmod.service) that performs this duty. It appears that the patch is in ostree and the ostree code fixes perms on /sysroot/tmp. Is that correct?  http://pkgs.fedoraproject.org/cgit/ostree.git/commit/?id=a152e3121f4e76e0265139a613313d7d233730ae
Comment 27 Colin Walters 2015-11-18 17:33:59 UTC
Comment 28 Dusty Mabe 2015-11-18 17:41:34 UTC
So was it just an oversight to leave the git commit message like it was: "Add ostree-tmp-chmod.service to fix /tmp permissions on existing installs."
Comment 29 Fedora Update System 2015-11-19 09:53:28 UTC
ostree-2015.9-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.