LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   777 directories and deleting files? (https://www.linuxquestions.org/questions/linux-security-4/777-directories-and-deleting-files-495612/)

emme0032 10-25-2006 10:48 PM

777 directories and deleting files?
 
The book my class is using "Advanced Programming in the Unix Environment"
Says that if you have write permissions on a directory you are able to delete any file within it.

The idea seems plain and clear.. A directory is simply a file with the I-node number followed by the name of that file.

Shouldnt it be possible to delete a file owned by any user from that directories content?
Or at least rename it?

I tried some experiments and using basic command line I wasnt able to do what the books says is true. Should I take this a step further and try a progamtic approach?


Any ideas? This is rather interesting to me.

btmiller 10-26-2006 12:36 AM

If the directory permissions are 0777 and users can delete other users' files. If they are 1777 (i.e. if the "sticky bit" is set) users can only delete or move their own files (unless you're root, of course).

emme0032 10-26-2006 01:35 AM

Perfect! Thanks for the answer.

I've seen on my past hosting company that the /home/ was 0777. That probably means they were hacked? Doesnt seem like an admin would do that.
Any user could become any other user by doing this:
delete /home/fred
remake /home/fred
add whatever commands you want to /home/fred/.login or whatever script is used..
when fred connects with ssh your script is executed.

Does that seem like a valid attack vector? Good thing I pay more than 5$ for my hosting now.

Quigi 10-26-2006 09:34 AM

Even if you have write (and execute!) access to /home, you could not delete /home/fred if it was a directory with anything in it. Only if in addition you had write and execute access to /home/fred (and any subdirectories that it might contain) you could empty it, and delete it.

I agree that /home should not be 777 -- anyone could create anything there.

poweredbydodge 10-31-2006 11:27 AM

Quote:

Originally Posted by Quigi
Even if you have write (and execute!) access to /home, you could not delete /home/fred if it was a directory with anything in it.

i found the best way to 'force teach' myself about file permissions was to bash myself over the head with ftp for a little while.

when you're setting up an ftp server conf file, you don't want to sit there for 30 hours typing out every single command and whether or not user a, b, or c can use those commands in a given directory or tree of directories.

in short... most viewing and reading commands, whatever they may be, fall under LIST (for ftp) which translates to READ (or VIEW) on your operating system. most write, delete, edit, make new file, make new directory, delete directory, move file, cut and paste file commands fall under WRITE (for ftp) and WRITE (for your os). executable files are a no brainer... execute is just EXECUTE.

This is why the chmod string (minus the sticky bit) is really only 3 numbers... 644 for home dir's... 777 for universal access... those 3 numbers correlate to 3 types of permission.

1st number = READ (R)
2nd number = WRITE (W)
3rd number = EXECUTE (X)

If you ever look at a directory in "list" mode instead of "icon" mode, you'll be able to see the file attributes and directory attributes... often they'll be done like this...

fileA .................. -r-w-x
fileB .................. -r----
fileC .................. -r---x
fileD .................. ----x

fileA can be read / written / and executed (thats your 777)
fileB can be read, but not written or executed
fileC can be read and executed but not written, so you can't delete it!

fileD is great too, you can ONLY execute it. why is this good?
let's say you're a programmer in a test environment cluster. you've put together a great little script or module or whatever, and you and you share it with your coworkers before giving it off to the boss. well coworker A turns out to be a jerk, and wants to snag your idea by ripping off your code and taking it to the boss first... nope, can't do it, he can execute the file, but he can't read it in a text editor or anything else. aww... poor lil guy. of course, root overrides all of this, but unless his buddy is the system admin, then you're safe.

happy linuxing


All times are GMT -5. The time now is 07:29 PM.