| 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> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 23 | CC: | acarter, kparal, mattdm, mbarnes, mruckman, pbrobinson, walters | ||||||
| Target Milestone: | --- | Keywords: | CommonBugs, Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F23_bugs#atomic-bad-tmp-permissions | ||||||||
| 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 09:53:31 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Dusty Mabe
2015-10-30 20:41:25 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. (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? 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`. (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. I'm not really sure it makes sense to release the F23 Atomic Host with this. 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. ostree-2015.9-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd4760d0fc Additionally, this can't be a blocker because it only affects Atomic (aiui). However, I did update the CommonBugs page with this workaround. 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 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. I'll investigate writing a systemd unit file for this. 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. should we re-open and close once the systemd unit is in place? re-opening to track creation of systemd unit for acarter 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 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.
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 ? 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?
(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.) (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. LGTM. Did you test it? (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. ostree-2015.9-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-5f8e9e7d20 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 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 That's correct. 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." 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. |