Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tmpfiles: R! /dir/.* destroys root #5644

Closed
jsynacek opened this issue Mar 27, 2017 · 7 comments
Closed

tmpfiles: R! /dir/.* destroys root #5644

jsynacek opened this issue Mar 27, 2017 · 7 comments

Comments

@jsynacek
Copy link
Contributor

jsynacek commented Mar 27, 2017

Do NOT run the reproducer without a proper backup and/or on a production system!

How to reproduce:

  1. # mkdir -p /foo/dir{1,2}
  2. # touch /foo/.bar{1,2}
  3. # cat /etc/tmpfiles.d/test.conf
    R! /foo/.* - - - - -
  4. Reboot.

Note the dot in the glob. When either using r!, or removing the dot and using R!, the bug doesn't reproduce.

@jsynacek jsynacek changed the title tmpfxles: R! /dir/.* destroys root tmpfiles: R! /dir/.* destroys root Mar 27, 2017
jsynacek pushed a commit to jsynacek/systemd that referenced this issue Mar 28, 2017
@poettering
Copy link
Member

I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?

@jsynacek
Copy link
Contributor Author

No, not on Fedora 24 at least.

@louiz
Copy link

louiz commented Apr 7, 2017

no?

No

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html#tag_20_111_16

The rm utility is forbidden to remove the names dot and dot-dot in order to avoid the consequences of inadvertently doing something like:

rm -r .*

@csirac2
Copy link

csirac2 commented Apr 16, 2017

Here's the regression tests in coreutils https://github.com/coreutils/coreutils/blob/e7a2580b96370da03c4d3553ccdf4ee66a14c6a4/tests/rm/r-4.sh#L39 which includes the rm -rf .//// case.

@rysiekpl
Copy link

For some people it's advisable to never miss a chance to stay silent.

Debian:

root@5afb081909c8:/# mkdir /foo/
root@5afb081909c8:/# rm -rf /foo/.*
rm: refusing to remove '.' or '..' directory: skipping '/foo/.'
rm: refusing to remove '.' or '..' directory: skipping '/foo/..'

Ubuntu:

root@b5d54715a834:/# mkdir /foo/
root@b5d54715a834:/# rm -rf /foo/.*
rm: refusing to remove '.' or '..' directory: skipping '/foo/.'
rm: refusing to remove '.' or '..' directory: skipping '/foo/..'

Busybox:

/ # mkdir /foo/
/ # rm -rf /foo/.*
rm: can't remove '.' or '..'
rm: can't remove '.' or '..'

It took a whole of 5mins to test all of these.

I find it particularly interesting since the comment I am referring to has been made after the issue has been solved already. Way to highlight how little consideration is being given to issues reported by systemd users. Bodes well for the whole project!..

@thelounge-zz
Copy link

I am not sure I'd consider this much of a problem.

shocking to hear

Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?

no, and you REALLY should know that as many others do or AT LEAST test it before pretend such nonsense - frankly, that below is not something theoretical, i do that for many years to get /tmp/ really empty

[root@testserver:/tmp]$ rm -rf .
./ ../ .font-unix/ .ICE-unix/ .Test-unix/ .X11-unix/ .XIM-unix/
[root@testserver:/tmp]$ rm -rf .*
rm: Entfernen von '.' Verzeichnis '..' nicht möglich: '.' wird übersprungen
rm: Entfernen von '.' Verzeichnis '..' nicht möglich: '..' wird übersprungen

@thelounge-zz
Copy link

and look how others see it as "much of a problem" when something by accident kills the whole OS - and yes i am terrible angry by that comment which shows something of an bad attitude

[root@testserver:~]$ rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

@systemd systemd locked and limited conversation to collaborators Apr 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

6 participants