Discrepancy with the output of `ls -al` and `getfacl`
Clash Royale CLAN TAG#URR8PPP up vote
2
down vote
favorite
I have run the following script to set permissions into /etc/nginx
#!/usr/bin/env bash
sudo chown -R root:root /etc/nginx
sudo chmod -R 0750 /etc/nginx
sudo setfacl -Rbk -m g:hugo:rwx /etc/nginx
sudo setfacl -R --mask -m g:www-data:rx /etc/nginx
However, when I check the permissions afterwards there is a discrepancy in the results for the 'group' of ls -al and getfacl
$ ls -al /etc/nginx
total 24
drwxrwx---+ 5 root root 4096 Mar 18 17:07 .
$ getfacl /etc/nginx
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx
# owner: root
# group: root
user::rwx
group::r-x
group:www-data:r-x
group:hugo:rwx
mask::rwx
other::---
Why?
chmod acl 18.04
asked Mar 18 at 17:17
Hugo
421312
add a comment |Â
up vote
2
down vote
favorite
I have run the following script to set permissions into /etc/nginx
#!/usr/bin/env bash
sudo chown -R root:root /etc/nginx
sudo chmod -R 0750 /etc/nginx
sudo setfacl -Rbk -m g:hugo:rwx /etc/nginx
sudo setfacl -R --mask -m g:www-data:rx /etc/nginx
However, when I check the permissions afterwards there is a discrepancy in the results for the 'group' of ls -al and getfacl
$ ls -al /etc/nginx
total 24
drwxrwx---+ 5 root root 4096 Mar 18 17:07 .
$ getfacl /etc/nginx
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx
# owner: root
# group: root
user::rwx
group::r-x
group:www-data:r-x
group:hugo:rwx
mask::rwx
other::---
Why?
chmod acl 18.04
asked Mar 18 at 17:17
Hugo
421312
Becausels -ldoesn't show access control list attributes. It merely shows their pure existance by means of the+sign. That is: whenever you see a+in the permissions, issuegetfaclafterwards.
– PerlDuck
Mar 18 at 17:26
1
Doesn't getfacl list the POSIX permissions too though? Isn't that whatgroup::r-xis in the output?
– Hugo
Mar 18 at 17:33
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I have run the following script to set permissions into /etc/nginx
#!/usr/bin/env bash
sudo chown -R root:root /etc/nginx
sudo chmod -R 0750 /etc/nginx
sudo setfacl -Rbk -m g:hugo:rwx /etc/nginx
sudo setfacl -R --mask -m g:www-data:rx /etc/nginx
However, when I check the permissions afterwards there is a discrepancy in the results for the 'group' of ls -al and getfacl
$ ls -al /etc/nginx
total 24
drwxrwx---+ 5 root root 4096 Mar 18 17:07 .
$ getfacl /etc/nginx
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx
# owner: root
# group: root
user::rwx
group::r-x
group:www-data:r-x
group:hugo:rwx
mask::rwx
other::---
Why?
chmod acl 18.04
asked Mar 18 at 17:17
Hugo
421312
I have run the following script to set permissions into /etc/nginx
#!/usr/bin/env bash
sudo chown -R root:root /etc/nginx
sudo chmod -R 0750 /etc/nginx
sudo setfacl -Rbk -m g:hugo:rwx /etc/nginx
sudo setfacl -R --mask -m g:www-data:rx /etc/nginx
However, when I check the permissions afterwards there is a discrepancy in the results for the 'group' of ls -al and getfacl
$ ls -al /etc/nginx
total 24
drwxrwx---+ 5 root root 4096 Mar 18 17:07 .
$ getfacl /etc/nginx
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx
# owner: root
# group: root
user::rwx
group::r-x
group:www-data:r-x
group:hugo:rwx
mask::rwx
other::---
Why?
chmod acl 18.04
chmod acl 18.04
asked Mar 18 at 17:17
Hugo
421312
asked Mar 18 at 17:17
Hugo
421312
asked Mar 18 at 17:17
Hugo
421312
asked Mar 18 at 17:17
Hugo
421312
asked Mar 18 at 17:17
Hugo
421312
421312
Becausels -ldoesn't show access control list attributes. It merely shows their pure existance by means of the+sign. That is: whenever you see a+in the permissions, issuegetfaclafterwards.
– PerlDuck
Mar 18 at 17:26
1
Doesn't getfacl list the POSIX permissions too though? Isn't that whatgroup::r-xis in the output?
– Hugo
Mar 18 at 17:33
add a comment |Â
Becausels -ldoesn't show access control list attributes. It merely shows their pure existance by means of the+sign. That is: whenever you see a+in the permissions, issuegetfaclafterwards.
– PerlDuck
Mar 18 at 17:26
1
Doesn't getfacl list the POSIX permissions too though? Isn't that whatgroup::r-xis in the output?
– Hugo
Mar 18 at 17:33
Because
ls -l doesn't show access control list attributes. It merely shows their pure existance by means of the + sign. That is: whenever you see a + in the permissions, issue getfacl afterwards.– PerlDuck
Mar 18 at 17:26
Because
ls -l doesn't show access control list attributes. It merely shows their pure existance by means of the + sign. That is: whenever you see a + in the permissions, issue getfacl afterwards.– PerlDuck
Mar 18 at 17:26
1
1
Doesn't getfacl list the POSIX permissions too though? Isn't that what
group::r-x is in the output?– Hugo
Mar 18 at 17:33
Doesn't getfacl list the POSIX permissions too though? Isn't that what
group::r-x is in the output?– Hugo
Mar 18 at 17:33
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.
the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry
The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.
answered Mar 18 at 18:08
Thomas
3,21481325
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.
the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry
The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.
answered Mar 18 at 18:08
Thomas
3,21481325
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
add a comment |Â
up vote
1
down vote
accepted
What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.
the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry
The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.
answered Mar 18 at 18:08
Thomas
3,21481325
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.
the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry
The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.
answered Mar 18 at 18:08
Thomas
3,21481325
What you see with ls is the mask entry of the ACL. From man setfacl, the mask entry seems to reflect the maximum possible permissions that can be set on an ACL entry.
the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry
The access rights you see in your example with ls for the default group root:rwx are wrong as the effective rights are now controlled by the ACLs.
answered Mar 18 at 18:08
Thomas
3,21481325
answered Mar 18 at 18:08
Thomas
3,21481325
answered Mar 18 at 18:08
Thomas
3,21481325
answered Mar 18 at 18:08
Thomas
3,21481325
3,21481325
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
add a comment |Â
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
Crazy stuff, I guess it's meant to do that?
– Hugo
Mar 18 at 22:20
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1017052%2fdiscrepancy-with-the-output-of-ls-al-and-getfacl%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Because
ls -ldoesn't show access control list attributes. It merely shows their pure existance by means of the+sign. That is: whenever you see a+in the permissions, issuegetfaclafterwards.– PerlDuck
Mar 18 at 17:26
1
Doesn't getfacl list the POSIX permissions too though? Isn't that what
group::r-xis in the output?– Hugo
Mar 18 at 17:33