Bug 1436004
| Summary: | Unexpected, catastrophic behavior from systemd-tmpfiles | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Tom Kelliher <kelliher> |
| Component: | systemd | Assignee: | Jan Synacek <jsynacek> |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Sumsal <fsumsal> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | fsumsal, jsynacek, lnykryn, saime, systemd-maint-list |
| Target Milestone: | rc | Keywords: | Patch |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-219-58.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 11:32:10 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: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1546552, 1549617, 1551061 | ||
You want to use r! instead of R! if you want to use that glob. The problem here is, that tmpfiles did exactly what you asked then to do. For glob /foo/.* it will also match /foo/.. which is /. But I agree that this behavior is kinda dangerous and should be changed. I had forgotten about '..'. Thanks for enlightening me. The behavior is kinda dangerous, but entirely consistent. At the very least, this experience gave me the opportunity to put my dump/restore strategy to the test, during which I came across a bug while restoring a level 1 dump, but that's for another bug report. Thank you for your responses. Merged upstream. How to test:
1) # mkdir -p /foo/bar/dir{1,2}
2) # touch /foo/bar/file{1,2}
3) # echo "R /foo/bar/.* - - - - -" > /etc/tmpfiles.d/test.conf
4) # systemd-tmpfiles --remove
5) # ls /foo
/foo will be empty if the bug reproduces.
A better reproducer...
$ cat rep.sh
#!/bin/sh
mkdir -p /foo/bar/.dir{1,2}
mkdir -p /foo/bar/dir{3,4}
touch /foo/bar/.file{5,6}
touch /foo/bar/file{7,8}
systemd-tmpfiles --remove
ls -la /foo/bar
The expected input is something like
drwxr-xr-x 4 root root 4096 Mar 29 10:25 .
drwxr-xr-x 3 root root 4096 Mar 29 10:07 ..
drwxr-xr-x 2 root root 4096 Mar 29 10:07 dir3
drwxr-xr-x 2 root root 4096 Mar 29 10:07 dir4
-rw-r--r-- 1 root root 0 Mar 29 10:25 file7
-rw-r--r-- 1 root root 0 Mar 29 10:25 file8
When the bug reproduces, 'ls -la /foo/bar' fails with
ls: cannot access '/foo/bar': No such file or directory
(In reply to Jan Synacek from comment #6) > Merged upstream. My original patch was merged, but it does solve only a small part of the issue. Much better solution is being implemented in https://github.com/systemd/systemd/pull/5809/. Backporting the upstream fixes turned out much harder than it looked. Moving to RHEL-7.5. fix merged to staging branch -> https://github.com/lnykryn/systemd-rhel/pull/208 -> post Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3245 |
Description of problem: A tmpfiles.d entry of the form R! /foo/.* appears to be interpreted by systemd-tmpfiles as something similar to R! / destroying the filesystem. Version-Release number of selected component (if applicable): 219-30.el7_3.7 How reproducible: Consistently reproducible. Steps to Reproduce: 1. Create the directory /foo. 2. In /etc/tmpfiles.d create the file foo.conf containing the one line R! /foo/.* 3. Reboot. 4. Wait several minutes; the system won't come up to the user login stage. 5. Reboot a second time. Actual results: Grub reports that it can't find /grub2/i386-pc/normal.mod and drops into rescue mode. The filesystem appears to be destroyed. Expected results: dot files and directories in /foo/ are (recursively) removed. Additional info: None.