Re: File Permissions are incorrect. Security flaw in Linux

[mru@users.sourceforge.net (Måns Rullgård)]

"Lisa R. Nelson" <lisanels@cableone.net> writes:

> [1.] One line summary of the problem:    
> A low level user can delete a file owned by root and belonging to group
> root even if the files permissions are 744.  This is not in agreement
> with Unix, and is a major security issue.
>
> [2.] Full description of the problem/report: 
>     Permissions on a file basis take precedence over directory
> permissions (for most cases), but in Linux they do not.  In order to
> secure a file, you have to secure the directory which effects all files
> within it.  
>     As user 'lisa', I do all my work on my server.  One task is to move
> pictures from my digital camera to my server picture directory that is
> wide open to everyone.  All users can create sub-folders and put
> pictures in there.  But every hour I have a cron job run that changes
> the ownership to root, and sets the permissions to 644 on all files in
> that directory structure.  Thinking the files could no longer be altered
> by anyone but root (as would be the case in unix), and found anyone
> could delete them.  That's when I discovered this major bug.

This is not a bug.  Deleting a file is in effect a modification to the
directory containing the file, not to the file itself.  If the file
has a hard link in another directory, it will still remain there,
unmodified.  If you want only the owner of a file to be able to delete
it, set the sticky bit on the directory containing it, like this:

chmod 1777 /the/dir

This is commonly used on /tmp.  It is also the all Unix systems I've
been using work.

-- 
Måns Rullgård
mru@users.sf.net