2

I've got a directory and a file in it, with the directory marked as read-only:

$ mkdir directoryname
$ touch directoryname/filename
$ chmod a-w directoryname

I cannot delete the file, even if pass the -f flag to rm:

$ rm -f directoryname/filename
rm: cannot remove `directoryname/filename': Permission denied

Is there a way to force rm to delete this file? Obviously, I could temporarily give directoryname write permissions, but I'm looking for a more convenient way.

I believe the underlying unlink syscall fails in the same way. Is there a way to get around that?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Flimm
  • 3,970
  • 7
  • 28
  • 36
  • 6
    If it where possible why would we need permissions? you are revoking write permission to the directory which implies delete, therefore you are not allowed to write/delete. You may be looking for a `chmod 755` which will allow you to write/delete but won't allow your group nor others. – YoMismo Aug 01 '14 at 11:31
  • It's possible to delete read-only files with `rm -f`, but not files in read-only directories. I'm just looking for a convenient one-line command, I know why it fails by default. – Flimm Aug 01 '14 at 12:21

1 Answers1

3

What about:

sudo rm directory/filename

or:

su -c "rm directory/filename"

depending on your distro and/or setup.

You are giving yourself a temporary root for the duration of the above commands and as root is almighty on Unix/Linux you are allowed to do anything. This contrasts with MS Windows where you can remove access to the administrator account (although there are ways around that).

SELinux can help as can various extended attributes tools (such as chattr) but in the end, they can be bypassed as root can alter the extended attributes and can configure (and even disable) SELinux.

garethTheRed
  • 33,289
  • 4
  • 92
  • 101
  • Why does root have extra privileges that even the owner of the directory and file doesn't have? – Flimm Aug 01 '14 at 11:33
  • 1
    That is OK if you are in the sudoers or can be root. – YoMismo Aug 01 '14 at 11:33
  • @Flimm - Root is the admin of the entire system. So ofcourse the root has permissions to do almost anything. You can Google more information on this. – Stark07 Aug 01 '14 at 12:13
  • @Flimm, Unix was designed in such a way that the **root** user can do anything, unrestricted by the kernel. Only recent additions like the immutable file attribute (see the [`chattr`](http://man7.org/linux/man-pages/man1/chattr.1.html) or [`chflags`](http://www.freebsd.org/cgi/man.cgi?query=chflags&sektion=1) commands) or SELinux can limit **root**'s power. – Cristian Ciupitu Aug 01 '14 at 12:52
  • 1
    On FreeBSD you can increase the [security level](http://www.freebsd.org/cgi/man.cgi?query=init) to 1 so that the system immutable and system append-only flags may not be turned off. Any super-user process can raise the security level, but no process can lower it, so the only way to get back to 0 is by rebooting. – Cristian Ciupitu Aug 01 '14 at 16:01
  • The same goes for SELinux. It can be configured in such a way, that it's practically impossible to disable it. See for example Russell Coker's [SELinux Play Machines](http://www.coker.com.au/selinux/play.html). – Cristian Ciupitu Aug 01 '14 at 16:06
  • @CristianCiupitu - that SELinux Play Machine sounds quite impressive. – garethTheRed Aug 01 '14 at 16:32