Why wont these permissions work?

[Red Squirrel]

So I have a folder and I did a chmod -R 770 * and chown -R user:group * on it. So I have another user who I put in the group that this folder is set to. As far as I know, that user should be able to access that folder, but can't. Why is that?

Also, is there a way to actually get permissions to inherit? I hate how permissions are based on the process that creates/edits files and you end up with permissions that are all over the place with zero consistency. This is where NTFS is far superior and also is more versatile as you are not limited to just one group. I just want everything within a sub folder to have the same permissions across the board and any user added to the group to have access.

 

[Nothinman]

Virtually every Linux filesystem supports ACLs these days, but no one uses them because they're not usually needed and the complexity they add isn't worth it. And you don't have to use anything like the "effective permissions" tab in NTFS file properties, you just look at the file's permissions and you know who can do what with them.

Can that user read a file in that directory via the full path? Does that user have at least x access to all of the parent directories? If not, that's probably why they can't get into it.

 

[Emulex]

you need to walk the path

start with /usr
then /usr/home
then /usr/home/something
then /usr/home/something/finaldestination

check all the perms going down the line you will find something wrong.

unix is actually easier than inheritance to debug imo.

 

[Red Squirrel]

Right I forgot about needing the permissions for the full path. It's not feasible in this case as this directory's parent has info I would not want that user to see. I'll have to figure a different way, guess I'll move the folder somewhere else.

Though I find this system is one reason you'd never see Linux in an enterprise environment. Users will ask for the most wacked out permission schemes in enterprise environments, which NTFS will make a cakewalk somewhat... though it does become a nightmare to manage, but that's just because of the stupid crap users ask for, not so much the system.

 

[Red Squirrel]

Come to think of it, is there some kind of log somewhere I can check when troubleshooting permissions? Linux permissions are probably the biggest frustrating thing in everything having to do with computers, but having some kind of log would at least help troubleshoot.

Sometimes I just get so frustrated I just chmod 777 but that's not the right thing to do.

 

[Nothinman]

Right I forgot about needing the permissions for the full path. It's not feasible in this case as this directory's parent has info I would not want that user to see. I'll have to figure a different way, guess I'll move the folder somewhere else.

He just needs execute on the parent directories, not read.

Though I find this system is one reason you'd never see Linux in an enterprise environment. Users will ask for the most wacked out permission schemes in enterprise environments, which NTFS will make a cakewalk somewhat... though it does become a nightmare to manage, but that's just because of the stupid crap users ask for, not so much the system.

NTFS permissions are far from a cakewalk, if they were you wouldn't need the "Effective Permissions" tab on there to figure out rights a user actually has to a file. And both are about equally manageable if you use groups to manage those permissions properly.

And you see Linux in a ton of enterprise environments, just because you haven't seen it doesn't mean it doesn't exist.

Come to think of it, is there some kind of log somewhere I can check when troubleshooting permissions? Linux permissions are probably the biggest frustrating thing in everything having to do with computers, but having some kind of log would at least help troubleshoot.

No, there's no central permissions log. Each app has it's own and most (Apache comes to mind) are very good at explaining permissions errors when there is one. Linux permissions are very simple (minus the few odd special bits that you don't see much) so in order to keep running into these problems you're probably overthinking things or you never sat down and actually read up on how they work.

 

[Red Squirrel]

They are simple when there's only one user on the server, but as soon as you have different users and you want more than one user to have access to the same folder, and run into situations where you want inheritance, that's where it gets complicated. It would be nice to be able to say "I want all of this folder to be 770 and owned by root:somegroup" but instead every time a file is written it takes on random permissions and owner. I have lot of scripts to reset permissions to work around this, but to me that's really dirty.

An example that always pisses me off is I have a p2p VM and a p2p user, so all my torrents are done under this user, so I can't go under my main account to edit any of those files because they are taking on some permissions that don't allow the other user access, so I need to run a script just so I can go in.

I've been researching ACLs but not getting too far. I'm just finding articles telling me what they are, not how to implement them. Think that is my best bet if I want more advanced management.

 

[Nothinman]

They are simple when there's only one user on the server, but as soon as you have different users and you want more than one user to have access to the same folder, and run into situations where you want inheritance, that's where it gets complicated. It would be nice to be able to say "I want all of this folder to be 770 and owned by root:somegroup" but instead every time a file is written it takes on random permissions and owner. I have lot of scripts to reset permissions to work around this, but to me that's really dirty.

There's your problem, you clearly don't understand how permissions work. They don't take random permissions, they take the ownership of the user:group that created them unless the parent directly has the SGID bit set and then files are owned by the same group as that directory. And the permissions are 777 minus the umask of the creating process. This can be a bit of a pain sometimes, but most daemons let you specify that or you can change it in their startup scripts as well.

2s of Googling came up with this: http://tldp.org/LDP/intro-linux/html/sect_03_04.html

An example that always pisses me off is I have a p2p VM and a p2p user, so all my torrents are done under this user, so I can't go under my main account to edit any of those files because they are taking on some permissions that don't allow the other user access, so I need to run a script just so I can go in.

I've been researching ACLs but not getting too far. I'm just finding articles telling me what they are, not how to implement them. Think that is my best bet if I want more advanced management.

Quit trying to make Linux work like Windows and instead take the time to actually learn the proper Linux way of doing it.

 

[Red Squirrel]

So what you're saying is, Linux should not be used in a multi user environments where a user may need to access something accessible by another user? That seems pretty bad if that's really what it is.

So instead of trying to make it work with 2 users, just use 1 user for everything? That kinda defeats the purpose of having multiple users. My idea was if the p2p vm was to get compromised at least that user can't do much, but I still want my main account to access the same stuff that user can access. It semi works but it's very flaky and I usually have to go manually modify permissions because there's no proper inheritance so when the p2puser creates a file only that user can access it.

I also tried using force user and force group in samba but that only seems to work when it wants, and even if I got it to work it still does not fix locally accessing files.

This is just one thing that would be nice if they made better in Linux. The permission system is way too primitive and limited. It's not 1980 anymore.

 

[Nothinman]

So what you're saying is, Linux should not be used in a multi user environments where a user may need to access something accessible by another user? That seems pretty bad if that's really what it is.

If that's what you got out of my post, you need more help than is available here.

The permission system in Linux works fine, you're just not doing it right and you don't seem to have the ability to admit you're wrong or to grasp how it works. I'm not sure which. Linux was designed as multiuser from the get go, for you to believe it can't do that well is just mind boggling.

 

[Red Squirrel]

ok so if they're that great how do I make a folder where two users can have write access to it, but not anyone else, and if user 1 creates a file user 2 should also be able to read/write that file, including folders?

Without scripts that reset the permissions, and let's take samba out of the equation for now.

Now what if I also want another user to only have read only access to the files in that same folder? Or perhaps a user that can create new files but not delete them. Yeah, I just threw a monkey wrench into the whole thing now.

In general I prefer Linux over Windows, but permissions is one aspect that always frustrates me if I want anything slightly advanced.

This article pretty much echos all my feelings towards the Linux permissions:

http://marc.perkel.com/2005/04/04/unix-file-permissions-suck/

 

[Nothinman]

ok so if they're that great how do I make a folder where two users can have write access to it, but not anyone else, and if user 1 creates a file user 2 should also be able to read/write that file, including folders?

I just told you 2 posts ago. Add them to a common group, make that group the owner of the parent directory and set the SGID bit. Now any files created in that directory will have the same group as the parent directory.

username@mypc:/tmp$ umask
0007
username@mypc:/tmp$ mkdir blah
username@mypc:/tmp$ ls -ld blah/
drwxrwx--- 2 username username 6 Aug  1 19:53 blah/
username@mypc:/tmp$ chgrp disk blah/
username@mypc:/tmp$ ls -ld blah/
drwxrwx--- 2 username disk 6 Aug  1 19:53 blah/
username@mypc:/tmp$ cd blah/
username@mypc:/tmp/blah$ touch test1
username@mypc:/tmp/blah$ ls -l test1 
-rw-rw---- 1 username username 0 Aug  1 19:53 test1
username@mypc:/tmp/blah$ cd ..
username@mypc:/tmp$ chmod g+s blah/
username@mypc:/tmp$ touch blah/test2
username@mypc:/tmp$ ls -l blah/test*
-rw-rw---- 1 username username 0 Aug  1 19:53 blah/test1
-rw-rw---- 1 username disk    0 Aug  1 19:54 blah/test2

Now what if I also want another user to only have read only access to the files in that same folder? Or perhaps a user that can create new files but not delete them. Yeah, I just threw a monkey wrench into the whole thing now.

Yes, you would probably need an ACL to handle the extra read-only user, but that's simple enough although I don't know the setfacl syntax off the top of my head so I'm not going to type that out for you. Having a user only be able to delete files they've created is handled by the sticky bit, just like in /tmp.

But convoluted examples like you just provided should be avoided in both worlds and are better handled by proper business processes. And most things don't work well with your "create new files but not delete them" rights because even apps like Word fail outright with permissions like that because of their use of temporary files in the working directory. And not letting me delete files is pointless if I can write to the file itself because I can just as easily open the file, delete all of the contents and save it again.

Yes, NTFS permissions are more granular and flexible but that comes at a pretty huge price and virtually no one uses them like that.

In general I prefer Linux over Windows, but permissions is one aspect that always frustrates me if I want anything slightly advanced.

This article pretty much echos all my feelings towards the Linux permissions:

http://marc.perkel.com/2005/04/04/unix-file-permissions-suck/

I haven't read the link yet, but I stand by my original statement of "you're doing it wrong" if you're running into trouble this often. KISS because the more complexity you add the more difficult it is to understand and the more it costs to maintain. If you want to keep coming up with scenarios that make your life miserable, be my guest, but don't bitch when the system doesn't work the way you want when what you want doesn't make any sense.

 

[Red Squirrel]

I'll have to check out that SGID thing then. When I Googled on how to do inheritance I just got stuff telling me it was not doable.

As for the complex examples, it's the sad reality of the enterprise world. Users always want the most stupid permission schemes and almost seem to do on purpose to challenge us. The folder structures at work are brutal, but because it's NTFS these things are possible. Is it clean? not really, but it's not really NTFS's fault, it's the users for wanting these crazy schemes.

 

[silverpig]

I'll have to check out that SGID thing then. When I Googled on how to do inheritance I just got stuff telling me it was not doable.

As for the complex examples, it's the sad reality of the enterprise world. Users always want the most stupid permission schemes and almost seem to do on purpose to challenge us. The folder structures at work are brutal, but because it's NTFS these things are possible. Is it clean? not really, but it's not really NTFS's fault, it's the users for wanting these crazy schemes.

Sounds like you creates yourself a Powell Motors "Homer" (see the Simpsons episode).

If you let someone who doesn't know what they are doing design the thing, it'll be crap. The users shouldn't be telling the admin how to set the permissions, they should tell the admin what they want to be able to do, and the admin will then set up the accounts, directory structure, and permissions in an elegant way.

 

[Nothinman]

I'll have to check out that SGID thing then. When I Googled on how to do inheritance I just got stuff telling me it was not doable.

Because it's not inheritance in the same sense as NTFS permissions.

And once again, you should be googling on how to understand and use Linux permissions, not ways to make them work like NTFS.

As for the complex examples, it's the sad reality of the enterprise world. Users always want the most stupid permission schemes and almost seem to do on purpose to challenge us. The folder structures at work are brutal, but because it's NTFS these things are possible. Is it clean? not really, but it's not really NTFS's fault, it's the users for wanting these crazy schemes.

And it's part of your job to provide the best solution even it's not exactly what they want. Explaining to them why it's retarded to deny a user delete permission for a file they have write access to is part of the job, just blinding doing whatever they ask is a sure way to run an org into the ground.