[aklug] Re: interesting rm behavior

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.