LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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!

Notices


Reply
  Search this Thread
Old 09-29-2014, 10:01 AM   #16
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203

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 10:07 AM.
 
Old 09-29-2014, 10:07 AM   #17
maddyfreaks
Member
 
Registered: May 2011
Posts: 70

Original Poster
Rep: Reputation: 0
I have tested on other Linux boxes and I see the same issue
 
Old 09-29-2014, 10:09 AM   #18
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
In my box it's the same.. But as long as the permissions are applied correctly (755 with the exception of guser), I don't see why this should matter..
 
Old 09-29-2014, 10:30 AM   #19
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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...
 
1 members found this post helpful.
Old 09-29-2014, 10:43 AM   #20
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,402

Rep: Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489
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".
 
1 members found this post helpful.
Old 09-29-2014, 12:20 PM   #21
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 7,473
Blog Entries: 10

Rep: Reputation: Disabled
Smokey_justme...& rknichols:

Thanks for chiming in and helping-
 
Old 09-29-2014, 12:45 PM   #22
maddyfreaks
Member
 
Registered: May 2011
Posts: 70

Original Poster
Rep: Reputation: 0
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
./logs
$ ls -ld logs/
drwxrwxr-x+ 2 euser grpi 96 Sep 29 10:30 logs/
 
Old 09-29-2014, 01:21 PM   #23
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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)..

I hope I made myself clear this time
 
Old 09-29-2014, 01:35 PM   #24
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,402

Rep: Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489
Quote:
Originally Posted by maddyfreaks View Post
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
./logs
$ 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:
Code:
OPTIONS
   .
   .
   .
   -n, --no-mask
      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.
 
Old 09-29-2014, 02:48 PM   #25
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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 02:54 PM.
 
Old 09-29-2014, 03:56 PM   #26
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,402

Rep: Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489Reputation: 1489
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.
 
Old 09-29-2014, 04:06 PM   #27
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
The same thing as I said above... The ACL user/group permission is ANDed with the mask... Without the mask (using the -n option) the user doesn't have that permission, thus your result

Just to make things clear.. Using the -n switch without specifying the mask (e.g. m::rx) or without using it the -m switch on a file that already has a mask will void your command..

Here's an example:
Code:
smokey@desk:/home$ setfacl -b log  #this clears the ACL
smokey@desk:/home$ setfacl -n -m user:test:rwx log
smokey@desk:/home$ getfacl log
# file: log
# owner: smokey
# group: users
user::rwx
user:test:rwx			#effective:---
group::---
mask::---
other::---

Last edited by Smokey_justme; 09-29-2014 at 04:17 PM.
 
1 members found this post helpful.
Old 09-29-2014, 04:55 PM   #28
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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)

Code:
smokey@desk:/home$ ls -ld log
drwx------+ 1 smokey users 4 Sep 29 17:54 log
smokey@desk:/home$ setfacl -m mask::r log
smokey@desk:/home$ getfacl log
# file: log
# owner: smokey
# group: users
user::rwx
user:test:rwx			#effective:r--
group::---
mask::r--
other::---

smokey@desk:/home$ ls -ld log
drwxr-----+ 1 smokey users 4 Sep 29 17:54 log
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.

Code:
smokey@desk:/home$ setfacl -n -m user:test3:rx log #proper use of -n to avoid recalculations..
smokey@desk:/home$ getfacl log
# file: log
# owner: smokey
# group: users
user::rwx
user:test:rwx			#effective:r--
user:test3:r-x			#effective:r--
group::---
mask::r--
other::---

smokey@desk:/home$ ls -ld log
drwxr-----+ 1 smokey users 4 Sep 29 17:54 log
And the final one, we change the mask to rwx and our two users to read and execute only:
Code:
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
user::rwx
user:test:r-x
user:test3:r-x
group::---
mask::rwx
other::---

# 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
test3@desk:/home/log$ ls
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..
 
Old 09-29-2014, 05:11 PM   #29
maddyfreaks
Member
 
Registered: May 2011
Posts: 70

Original Poster
Rep: Reputation: 0
Thanks all
 
Old 09-29-2014, 06:18 PM   #30
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 7,473
Blog Entries: 10

Rep: Reputation: Disabled
Quote:
Originally Posted by maddyfreaks View Post
Thanks all
Your Welcome-

Could you explain, what it was (something not set correctly) that was preventing you from what you were trying to accomplish. What solved it?

Was it because w/o the mask (using -n option) the user didn't have permission like Smokey_justme has already mentioned?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to remove access ACL set on 'others' in RHEL 6 P.B Linux - Newbie 11 07-23-2013 03:07 PM
[SOLVED] How to mount windows shared partitions and folder on rhel 6 with acl vikas637 Linux - Newbie 3 06-27-2011 08:05 AM
[SOLVED] Enable ACL in RHEL 5 yamujanu Linux - Security 2 05-26-2011 06:24 AM
ACL defaultmask issue leaded Linux - General 1 12-16-2009 07:18 AM
ACL problem? permission denied issue! teamgsi Linux - Enterprise 5 10-16-2009 05:47 PM


All times are GMT -5. The time now is 10:44 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration