DISCUSSION: Quick and Dirty Guide to Linux File Permissions

This thread is to discuss the article titled: Quick and Dirty Guide to Linux File Permissions

This article can be improved by touching on the chattr command as well

I see that the comments have dried up some time ago...

One suggestion, one comment: You could add some sentences about umask and what it does.

The comment is about this suid- "myscript" thing. I know it's just to show the recipe, but it suggests that it's ok to have such a script, while it's not. ("'myscript' is a shell script that we are writing that performs a useful function.") The target here are people new to Linux, and they may not know better. Fundamentally, such a script cannot be made unexploitable (path issues. temp file issues. IFS issues. Remaining race conditions that cannot be fixed. And so on and so on.) Because of that, the Linux kernel will not honor the suid bit for scripts, so on linux one is safe. But Solaris has no such inhibitions, for example.

Just my 5cts on this peripheral issue. Nice article!

mlp

Originally posted by mlp68 The comment is about this suid- "myscript" thing. I know it's just to show the recipe, but it suggests that it's ok to have such a script, while it's not. ("'myscript' is a shell script that we are writing that performs a useful function.") The target here are people new to Linux, and they may not know better. Fundamentally, such a script cannot be made unexploitable (path issues. temp file issues. IFS issues. Remaining race conditions that cannot be fixed. And so on and so on.) Because of that, the Linux kernel will not honor the suid bit for scripts, so on linux one is safe.

Firstly, i think that this is a very informative article. I really appreciate the authors help towards people who are new to Linux. This covers up pretty much everything that one needs to know about file permissions for basic usage.

Secondly, i think all that bashing from mlp68 was totally unwanted. As far as i know, no newbie will even think about 'myscript', they will concentrate on how to go ahead setting file permissions. I'm saying this from a newbie's point of view. I'm not a Linux 'Guru', but certainly not a newbie.

I know how a newbie (with considerable IQ) will think while reading the article and what he/she concludes from it.

I mean, how many newbies do you know who know anything about path issues, temp file issues, IFS issue etc??

Once again, i say that this is a very good article

Cheers

King Nothing

I wouldn't call my comment "bashing" - it's just a friendly comment.

M.

Maybe *Bashing* was an inappropriate word, but it did look like that to me.
No offense, but still all those things that you said were not necessary

King Nothing

I didn't consider it bashing, in fact I'm still trying to figure out what the hell mlp68 is talking about. It was just a random example, and i used the 'myscript' thing because I wanted to fit chmod + x into the example. Wouldn't work with an image or mp3 in the example would it .

BTW I just wanted to say that I did not add the parts about suid or the sticky bit, they were added by whoever proofread the article prior to posting it here.

Cheers folks....

Hi Bulliver,

first off, sorry if others perceived my comment as bashing. It's a great and well-written article. I was just referring to that paragraph

SETUID Normally, when a program is run it inherits all the rights/restrictions of the user that executed it. if a user can't read /var/log/messages, then neither can any program/script executed by that user. There is a way around this, we again use the chmod command but add a '4' at the beginning of the permission string, example: code:chmod 4755 myscript this would execute 'myscript' with the permissions of the files owner(such as root, if the file is own by root),and not the normal user executing 'myscript'. As you can imagine, this should be used sparingly if at all, as it defeats the normal permission structure,and can lead to security issues.

You say the right warning words, but since the linux kernel doesn't honor the SUID bit for scripts at all (because of the security flaws I listed, and some more), this wouldn't work. But worse, other flavors of Unix don't have those inhibitions about suid scripts, and that's where it could become dangerous (that's why I said a novice could take away from here that it is ok, while it's not). You can have a suid (or guid) executable, but not a script.

Have a look at http://www.phrack.org/phrack/47/P47-05 (question 10) which I just googled. It has a nice summary and explanation of the 4 easiest exploits. (There are more.)

Again, I didn't mean to diminish your great article, just point out this thing. Sorry if it came across the wrong way.

mlp

i think its a great article. i've never really understood how absolute modes worked because the explanations i've read ramble on about bits and such, but your illustration made it verry simple. thanks again

Thanks man, means a lot...

i think its a great article. i've never really understood how absolute modes worked because the explanations i've read ramble on about bits and such, but your illustration made it verry simple. thanks again

Hell YES !!!! this was in my mind all the time I was reading it. For the first time I get to understand that thingy.

And by it, I also inherited knowledge about WHAT in ALL heavens, my fstab should have for my winXP partitions and the DARN umask attribute !!!!!

This newbie has gotten alot of benefit from the article. THANKS !!

What I didnt see explained there, and still want to know (might be out of scope) is: How do I add a exacuatable to a specific group. (I.E. I want 'cdburn' to be executed by users in group 'cdwrite')

Qucho:

Thanks for your kind words, now for your question...

chown root:cdwrite cdburn 
chmod g+x cdburn

Thats it! All the info was in the guide...you just need to string the principles together.

btw, I used a colon in the chown command above, since using a period is now deprecated. Better update the guide....

Thanks again.

bulliver,

Thanks for everything. Yes, you are right, it is in the guide.

[edit] I readed the article a couple more times, and finally I got it right.

Seem to me I can not say 'thanks' enough times :P LOL...

You should mention console.perms (usually in /etc/security/). When it comes to devices permissions, it has the final word and chmod are useless. http://www.gentoo.org/doc/en/devfs-guide.xml#doc_chap4 gives more explanations.

Good guide about file permissions, also we have available "chattr" which I find very usefull. Let's say we want a direcotry with a read only permision. Probably there is more than way to set this directory read only, but using chattr is very easy.

chattr +i dir_name
Bingo! No body can write to it. Not even root.

These were my two cents,
Raxxal