Linux Permissions

So about every week, or maybe every couple days, I tend to post a thread about something I don't know enough about. It's that time again.

I'm familiar with chmod and chown, but the man pages aren't quite enough for me to be comfortable that I know how to use them safely. Are there friendly guides to managing file rights that you folks would recommend?

Confession:

I got audio working on my T400 last night, and in testing I needed some media so I mounted the ntfs volume using "sudo mount /dev/sda1 /mnt/ntfs". I then did "su root", copied the test music over to /home/mrb78s/music and did "chmod 777 -R" or something similar on those files. I then did "exit" to drop back to my regular user and continued on with my testing.

I know this is bad and clumsy, but its the only chmod command I knew off the top of my head and it gave me files to test with under my regular username. If I knew more about how rights work and how to manage them appropriately on Linux, I would do things like this a better way.

Well, I'm not 100% sure of what the question is, but I can explain a bit how the chmod and chown commands work.

Let's take the number in chown. It's 3 numbers ranging from 0 to 7. The first number refers to the user who owns the file, the second to the group that owns the file, and the third to all users. Each number is a composite. You separately control the read, write, and execute permissions (shown as r,w,x when you do an ls -l, or dashes if they are set to off).

Read=4
Write=2
Execute=1

Thus chmod 444 would give user, group, and world read permission, but not write or execute permission.

You can also add the numbers to get varying combinations. For example, 4+1=5, and 5 is read(4) and execute(1) permission. 6 would be read and write, but not execute. 0 is no permission at all.

chmod 755 would give the owner read, write, and execute permissions, but the group and world read and execute only (no write), as 7 is 4+2+1 and 5 is 4+1.

-R works on both chown and chmod and adds recursion. Dangerous to use on system directories, but often ok to use on your own home directory or directories of images, media, etc. Don't mess with system permissions if you don't have to, and if you do, use a scalpel, not an atom bomb. i.e. Make the smallest, most precise changes you can that will give you the needed functionality.

chown is a bit simpler. It takes the form chown user[:group] [-R] filename. The :group is optional, if it is omitted, it is implied that the argument is the user. If you wish to set both, you can list user and then a colon and then the group. Users generally have their own group. eg. If my user name is mrd, there is also a group called mrd. I can do chown mrd:mrd myfilename and it will set both the user and group to mrd.

In your case, with the chmod 777 that you used, it was probably not the ideal solution. Your goal was really to make those files owned by you, not by root, so chown imog:imog -R myfiles would have been preferable. The way you did it, they are still owned by root, but you can now read/write/execute them. Also, it makes no sense to make a file executable if it is not a program file (e.g. a media file cannot be executed). One sort of weird exception is directories. When a directory has the x bit set, that means that the user, group, or world, depending on where it's set, can cd into that directory and see its contents, so directories often are marked as executable, even though they are not, in the strictest sense, executables.

You can mount an ntfs partition and grant all users access to it if you want (read only or read write). You want to use the umask and dmask options, which are the bitwise masks of the 3 digits you use in chmod. So for example, umask=000 is like chmod 777. This is a mount time option that you can set in fstab or on the command line with a manual mount. I mount ntfs partitions on my PC at boot time in the /windows mountpoint that I created.

Thanks for the run-down MRD. Like IMOG, I had a tendency to just chmod 777 everything I needed rights to. I had read the wikipedia article on it, but this makes more sense.

MRD, somehow that was a lot more digestible than other things I've read. Thanks for taking the time to write that.

Linux man pages have a way of obfuscating the simple.

MRD said:

Linux man pages have a way of obfuscating the simple.

Click to expand...

I second that. All I want is an example, not an essay on features I will never use.

MRD said:

Linux man pages have a way of obfuscating the simple.

Click to expand...

I need that on a pillow or something... or maybe under "man obfuscate"

Totally agree fishy... a few simple examples would be 100x more useful.

MRD said:

Linux man pages have a way of obfuscating the simple.

Click to expand...

oh most definitely. i really hate it when you ask a question on a *nix forum and all you get is "read the man page"... irritating as hell since that is the first thing i do when i don't understand a command. they are more often than not, quite confusing. i don't know about the rest of the world, but i learn from example better.


thanks for the writeup you did there MRD.

i will save that for when we have new guys coming in on the job (if you don't mind). occasionally we get some guys who are not familiar with chown and chmod at work as they haven't had a ton of *nix experience and that seems to have explained it well. it would be nice for me to not have to explain it to them.

we have several solaris 9 boxes over in the UK that have cron jobs that reset the permission on files every so many minutes so any time we have to do code moves for them, you have to set permissions, take ownership, etc which can be a huge pain to explain to someone new. it is really bad when you are new and try to do a code move and the cron job executes in the middle of it and hoses the permissions...

on top of that, i get to type "/etc/sudo" every time i need sudo access because there are multiple versions of sudo on some our boxes... weird, i know but that is the unix team's decision, not mine

anyway, thanks for the info.

MRD - good writeup. I tend to take my understanding of most shell commands for granted these days.

burningcpu said:

Thanks for the run-down MRD. Like IMOG, I had a tendency to just chmod 777 everything I needed rights to. I had read the wikipedia article on it, but this makes more sense.

Click to expand...

LOL Can I have a shell account on your box? Thanks!

on top of that, i get to type "/etc/sudo" every time i need sudo access because there are multiple versions of sudo on some our boxes... weird, i know but that is the unix team's decision, not mine

Click to expand...

Only Solaris...why are they putting executable, SUID-root (of course sudo has to be SUID root!) binaries in /etc?

Meh.

Captain Newbie said:

MRD - good writeup. I tend to take my understanding of most shell commands for granted these days.



LOL Can I have a shell account on your box? Thanks!


Only Solaris...why are they putting executable, SUID-root (of course sudo has to be SUID root!) binaries in /etc?

Meh.

Click to expand...

i don't ask questions, i just work here

...even if i did, i would probably not get a decent answer. i am just happy that we are moving to redhat eventually. who knows how long that will take with 600+ servers out there. eek! that is what project my former boss is taking on now. he's a brave man...

mbentley said:

i don't ask questions, i just work here

...even if i did, i would probably not get a decent answer. i am just happy that we are moving to redhat eventually.

Click to expand...

Having used Solaris at $PREVIOUS_EMPLOYER, I can say that it's the only thing I'd be happy about moving to Dead Rat from.

Just so you all know, chmod --help gives a short synopsis of the command. Most coreutils programs have --help available, as do most programs in portage. (Indeed, these days, it's rare that there's not a short synopsis available from --help.)

Captain Newbie said:

Having used Solaris at $PREVIOUS_EMPLOYER, I can say that it's the only thing I'd be happy about moving to Dead Rat from.
*snip*

Click to expand...

i think they are moving to redhat is because they offer support. other distros don't have the kind of enterprise support that we need.
*end of hijack*

Having binaries in etc is really bizarre.

mbentley said:

on top of that, i get to type "/etc/sudo" every time i need sudo access because there are multiple versions of sudo on some our boxes... weird, i know but that is the unix team's decision, not mine

Click to expand...

I hate when people do stupid things.

MRD said:

Having binaries in etc is really bizarre.

Click to expand...

Things like shutdown and restore used to (like, old school *nix) live in /etc. (believe it or not.) I guess the thinking was they were 'miscellaneous programs'.

It violates our conventional notions of what /etc/ should and should not contain.

(/usr/portage should not be under /usr, it should be under /var, incidentally.)

I'll have to ask my dad about that... he was involved with the original Bell Labs Unix stuff way back.

{PMS}fishy said:

Code:

ln -s /etc/sudo sudo

which sudo

I hate when people do stupid things.

Click to expand...

haha but that isn't what was done...


they are really two different sudos on the system!