[aklug] Re: interesting rm behavior

On 12/24/2011 08:30 AM, bryanm@acsalaska.net wrote:
> On Sat, December 24, 2011 6:52 am, Royce Williams wrote:
>> bryanm@acsalaska.net said, on 12/24/2011 06:21 AM:
>>> I encountered interesting behavior of the 'rm' command. Here's
>>> what I did:
>>>
>>> bryan@atlantis:/tmp$ mkdir mydir
>>> bryan@atlantis:/tmp$ touch mydir/myfile
>>> bryan@atlantis:/tmp$ chmod u-w mydir
>>> bryan@atlantis:/tmp$ ls -la mydir
>>> total 3416
>>> dr-x------ 2 bryan users 8 2011-12-20 06:42 .
>>> drwxrwxrwt 14 root root 3461120 2011-12-20 06:42 ..
>>> -rw------- 1 bryan users 0 2011-12-20 06:42 myfile
>>> bryan@atlantis:/tmp$ rm -rf mydir
>>> rm: cannot remove `mydir/myfile': Permission denied
>>>
>>> Of course, "rmdir mydir" would fail because the directory is not
>>> empty, and "rm mydir/myfile" would fail because the user does not
>>> have permission to change the directory. I find it interesting,
>>> though, that "rm -rf" (unix's nuclear option) fails to perform
>>> the requested delete.
>>>
>>> When done as root, however, "rm -rf mydir" performs the deletion.
>>
>> FreeBSD provides a little more feedback, which may explain the behavior:
>>
>> royce@heffalump$ rm -rf mydir
>> rm: mydir/myfile: Permission denied
>> rm: mydir: Directory not empty
>
> That matches my understanding of why each individual deletion is not
> allowed, since it is (apparently) doing one piece at a time, rather
> than deleting the whole tree in one fell swoop.
>
> Upon further testing, even root cannot use rmdir on a non-empty
> directory. The difference between regular users and superusers is
> in the permission checking for rm -- apparently, there is none for
> root. Even a file with no permissions at all can be deleted by root
> (on my machine) without so much as using the --force option.
>
> Still, I find it interesting that a situation could arise in which
> a user may not be able to remove a tree of his/her self-owned files
> with "rm -rf". Going a step further, setting the "immutable"
> attribute could complicate things further.
>
> --
> Bryan Medsker
> bryanm@acsalaska.net
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
There was at least one thread where this topic was brought up:

https://consortiumlibrary.org/aklug/archive/2011-05/0068.html

I seem to remember there being another thread, where I complained about
the fact that my rsync backup system was disrupted because their was one
file in an original directory that had limited permissions. But I can't
find it. I think in the end we decided that I either had to make sure
that all my files were created with the correct permissions, or to run a
chmod -R on the origin directory before running rsync.

This thread my also be interesting, where we discussed how it is
possible to "create" a file that you cannot delete by hard linking to a
file owned by root:

https://consortiumlibrary.org/aklug/archive/2010-11/0187.html

-- 
frigidcode.com
theologia.indicium.us
-- Attached file included as plaintext by Ecartis --
-- File: signature.asc
-- Desc: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO9kJuAAoJEI2DxlFxTtgdKDsH/170UUbYtqRuFS8OSI2Tf2QJ
sKZ0A/j8CCZEtKOY+6U159jZWV4fGd+W+2C1uymMqNhupVKsPtwDEB+KQH4i6xCa
oIli4eF3Qhql82/fyQpNJ2h9V19An68Of6lhOZkDEiaO6iAOAnIVr4NvjZYajgnR
nrw7AsBnSY0rs2vBfXzy6a0Dsn9KQyKtOQWT4BhLXfb3JFNbON9n3Qh55bs/nc3b
xmRMf2AXGCzsW8sj7paoO3Xbx4LpZiyz9yXSjt0VNv/V7aENB2yi1KQpn/du0zl4
EUh5oHKLAEytfDxNA7XAFonOTZ6o1OgaRrWACwcOj0S437mK8kqJriWGfVz4KdE=
=y4We
-----END PGP SIGNATURE-----
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.