Bug 1276775 - [f23 - atomic] 755 perms on /tmp directory (symlink to /sysroot/tmp)
[f23 - atomic] 755 perms on /tmp directory (symlink to /sysroot/tmp)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ostree (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-30 16:41 EDT by Dusty Mabe
Modified: 2015-11-19 04:53 EST (History)
7 users (show)

See Also:
Fixed In Version: ostree-2015.9-2.fc23 ostree-2015.9-3.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 04:53:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ostree.spec patch (2.35 KB, patch)
2015-11-12 10:27 EST, Matthew Barnes
no flags Details | Diff
Patch ostree-remount.c (1.91 KB, patch)
2015-11-13 10:06 EST, Matthew Barnes
no flags Details | Diff

  None (edit)
Description Dusty Mabe 2015-10-30 16:41:25 EDT
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 17:03:48 EDT
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 17:06:55 EDT
(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 17:06:56 EDT
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 17:10:19 EDT
(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 17:15:35 EDT
I'm not really sure it makes sense to release the F23 Atomic Host with this.
Comment 6 Dusty Mabe 2015-10-30 17:19:59 EDT
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 18:08:27 EDT
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 18:47:41 EDT
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 01:56:27 EST
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 16:06:01 EST
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 15:50:58 EST
I'll investigate writing a systemd unit file for this.
Comment 12 Fedora Update System 2015-11-04 15:52:14 EST
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 10:11:32 EST
should we re-open and close once the systemd unit is in place?
Comment 14 Dusty Mabe 2015-11-06 11:03:02 EST
re-opening to track creation of systemd unit for acarter
Comment 15 Matthew Barnes 2015-11-12 10:27 EST
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 10:53:39 EST
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 11:09:26 EST
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 10:06 EST
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 10:09:02 EST
(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 10:12:08 EST
(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 10:18:35 EST
LGTM.  Did you test it?
Comment 22 Colin Walters 2015-11-16 10:32:48 EST
Building as http://koji.fedoraproject.org/koji/taskinfo?taskID=11868275
Comment 23 Matthew Barnes 2015-11-16 11:16:22 EST
(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 11:23:53 EST
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 11:53:01 EST
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 12:31:42 EST
The name of your git commit [1] 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? 

[1] http://pkgs.fedoraproject.org/cgit/ostree.git/commit/?id=a152e3121f4e76e0265139a613313d7d233730ae
Comment 27 Colin Walters 2015-11-18 12:33:59 EST
That's correct.
Comment 28 Dusty Mabe 2015-11-18 12:41:34 EST
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 04:53:28 EST
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.

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