Re: MiNT 1.09 security: f_delete() patch

[bousch@suntopo.matups.fr (Thierry Bousch)]

Hi Torsten,

>  Here's a patch which makes MiNT's f_delete() respect the sticky bit according
> to the semantic how I understand it and hope it really is... Well, at least
> it's better and/or a bit more secure than it is now... :-)

Hmm, if you want to support the sticky bit, you must also patch the
f_rename() and f_rmdir() functions, because you shouldn't be allowed to
rename/move files and subdirectories of a sticky folder. (Otherwise, it
would be a big security hole: you could move files to a non-sticky
folder, and delete them.)

>  It goes like this:
> 
>  If I haven't write permission to the parent directory, I loose. Otherwise,
> if the sticky bit isn't set, I can delete anything regardless of its mode
> or if it's mine at all. If the sticky bit is set, I can only delete a file
> if it's mine, or if the whole directory is mine. In the last case I again can
> delete every file in the directory.

In RAMFS 1.4, the sticky bit is implemented as follows. (The kernel has
already checked permissions, but ignores the sticky bit). IF the sticky
bit of the directory is set, AND if you're not the super-user, AND if
your real uid is not the one of the "item" (file/subdirectory/link)
you're trying to move/remove, THEN the file-system returns EACCDN.

This means that you cannot move/remove files you don't own in a
directory you own, but this is not really a problem, since you can
modify the permissions of your directory :-)

By the way, what is the usual semantics for the setuid and setgid flags
on directories?

Thierry.