Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
The directory is still 755... Don't know why ls is showing 775 (bug?) ... I've even tested it (see my later edited upper post)... You can also clearly see in the output of getfacl that group doesn't have write permissions (mask doesn't interfere with this and is never an effective permission by it's own)
Last edited by Smokey_justme; 09-29-2014 at 11:07 AM.
It seems the ls behavior is normal and logical... Because ls only shows you normal permissions, even if just one user from the group has a certain extended permission that permission will appear as set on the list signalling that there is a write permission in the group, rather then letting you think no user has it.. I didn't notice until now..
Anyway, in case of acl's it's always better to use getfacl, it seems...
The ls command includes in the "group" permissions any rights granted by ACLs for named users and groups. The "+" at the end of the permissions should be taken to mean, "You need to use getfacl to see what the actual permissions are." If you do that, you will see that the "group" permissions are still "r-x" and only the named user and the owner have "rwx".
It is true what rkinchols said... Test it with actual users if you don't trust us...
The thing is that ACLs are an extension of the normal permissions set with backward-compatibility in mind... The tools don't really need to be aware of this and for compatibility reasons, they aren't. The system calls (from the kernel) handle everything in the background and as a convention, it will rather report a false permissive permission than report a false restrictive permission.. Keep in mind that when using ACLs, they simply can't return the truth (which can't be represented in a simple 'drwxrwxrwx- user:group' string). So you always need to keep in mind that when asking any tool for such a string it will (only!) report a false permisive permission. But!, when a user actually tries to apply it's permission or even request permission details (for example if [ -w file ]; then ..) the real result will be returned (in your case, euser and guser will have permissions to write new files or delete old file to/from the directory and any other user will not have -- modifying files is on a file basis)..
rkinchols - if what ever you are saying is correct then the find with permissions should not report this ... but its reporting...
$ cd /opt/euser
$ find . -type d -perm 0775
$ ls -ld logs/
drwxrwxr-x+ 2 euser grpi 96 Sep 29 10:30 logs/
OK. Looks like it's the setfacl command itself that is recalculating those permissions. Here is the relevant part from the setfacl manpage:
Do not recalculate the effective rights mask. The default behavior of set-
facl is to recalculate the ACL mask entry, unless a mask entry was explic-
itly given. The mask entry is set to the union of all permissions of the
owning group, and all named user and group entries. (These are exactly the
entries affected by the mask entry).
While it's not clear from that language, it apparently is referring to what is stored in the st_mode field of the inode, which is what ls displays and find tests. At least that's what the testing I've been able to do implies.
Actually the -n option only affects the acl mask (which is not part of the normal permissions either).. By default, if the file doesn't already have a 'mask::---' (ACL_MASK_OBJ) set, setfacl will write one that fits your desired permission. The mask field is required and gets ANDed with the USER and GROUP ACL (just ACL) entries to generate the final permissions (it's also a way to quickly shut-off extra access to a file)
So no, that option doesn't change a thing (since, I repeat, mask has nothing to do with the old unix permissions)..
Last edited by Smokey_justme; 09-29-2014 at 03:54 PM.
Well, when I try adding permission for an individual and use "-n", then the added permission does not show up in either the output from either "ls -l" or "stat", or if I "stat" the inode in debugfs. If I do not use "-n", then it shows up in all three places. It's hard to reconcile that with the way things "should" work.
And just to make things even clearer.. Another few examples (continuing the above):
Now we're setting the mask to 'read', which will give us an effective read permission for user test and will cause ls to show drwxr-----+ even if users from the group users can't effectively read the directory (except for test which is in our ACL)
And now we're introducing the test3 which isn't part of the users group and give him read and execute permissions. We will use '-n' so that our mask isn't recalculated and transformed to the most permissive form. If we we're to omit '-n' then our mask would became rwx because the test user requires it.
And the final one, we change the mask to rwx and our two users to read and execute only:
smokey@desk:/home$ setfacl -m user:test:rx,user:test3:rx,mask::rwx log
smokey@desk:/home$ getfacl log
# file: log
# owner: smokey
# group: users
# Now ls is showing the mask instead of group permissions or effective permissions
smokey@desk:/home$ ls -ld log
drwxrwx---+ 1 smokey users 4 Sep 29 17:54 log
# The owner has write
smokey@desk:/home$ touch log/test_smokey
# test (group 'users') does not have write and is denied access despite what ls is showing
test@desk:/home$ touch log/test_test
touch: cannot touch 'log/test_test': Permission denied
# test2 (group 'users') does not have any kind of permission despite what ls is showing
test2@desk:/home$ touch log/test_test2
touch: cannot touch 'log/test_test2': Permission denied
test2@desk:/home$ cd log
bash: cd: log: Permission denied
# test3 (not in group 'users') does not have write permission but has read and execute, despite what ls is showing for "others"
test3@desk:/home$ touch log/test_test3
touch: cannot touch 'log/test_test3': Permission denied
test3@desk:/home$ cd log
a b test_smokey
P.S. So I was wrong.. ls (and other tools) shows the mask at group when ACLs are involved.. However that does not change the effective permission..