Setfacl is failing: Operation Not Supported

devUnix · 11-18-2013, 02:06 PM

I have to assign red/execute permission on the following directory to this group: GSG-MDP-Developers

Code:

# getfacl /home/dkpartners
getfacl: Removing leading '/' from absolute path names
# file: home/dkpartners
# owner: dkpartners
# group: dkpartners
user::rwx
group::---
other::---

but it is failing:

Code:

# setfacl -R -m d:group:GSG-MDP-Developers:rx /home/dkpartners
setfacl: /home/dkpartners: Operation not supported
setfacl: /home/dkpartners/dkpartners_enhanced_file-1.0: Operation not supported
setfacl: /home/dkpartners/dkpartners_enhanced_file-1.0/config: Operation not supported
setfacl: /home/dkpartners/dkpartners_enhanced_file-1.0/history: Operation not supported
setfacl: /home/dkpartners/dkpartners_enhanced_file-1.0/upload: Operation not supported
#

If I remove the "d" option then the list of the sub-directories/files is very long and the error is the same: Operation not supported.

Of course, the group does exist and there are users in it.

What am I missing here?

I have also tried:

Code:

# setfacl -m d:group:GSG-MDP-Developers:rx /home/dkpartners
setfacl: /home/dkpartners: Operation not supported
# setfacl -m group:GSG-MDP-Developers:rx /home/dkpartners
setfacl: /home/dkpartners: Operation not supported

Note:

Code:

# cat /etc/issue
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
Kernel \r on an \m

#

I created a test directory and am getting the same error:

Code:

# mkdir test
# getfacl test
# file: test
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# setfacl -m g:GSG-MDP-Developers:6 test
setfacl: test: Operation not supported

druuna · 11-18-2013, 02:19 PM

Just a thought: Is the acl options present in your fstab file?

The partition that you want to use setfacl on must be mounted with the acl option:

Code:

/dev/mapper/VG_SYST-LV_HOME       /home           ext4  defaults,acl        0 2

devUnix · 11-18-2013, 02:28 PM

Code:

# df -hT .
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda3     ext3    132G   22G  103G  18% /
# grep /dev/sda3 /etc/fstab
/dev/sda3               /                       ext3    defaults        1 1
#

Besides, SELinux is disabled on the host:

Code:

# getenforce
Disabled
# sestatus
SELinux status:         disabled

I just had a chat with my senior colleague and he said that since SELinux is Not Enabled, this exercise would be meaningless and hence he suggested me to use "chmod" instead. But using "chmod" would permit other people to have r/x permissions too.

druuna · 11-18-2013, 02:37 PM

Quote:

Originally Posted by devUnix

Code:

# df -hT .
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda3     ext3    132G   22G  103G  18% /
# grep /dev/sda3 /etc/fstab
/dev/sda3               /                       ext3    defaults,acl        1 1
#

I fixed it for you

Quote:

Besides, SELinux is disabled on the host:

Code:

# getenforce
Disabled
# sestatus
SELinux status:         disabled

I just had a chat with my senior colleague and he said that since SELinux is Not Enabled, this exercise would be meaningless and hence he suggested me to use "chmod" instead. But using "chmod" would permit other people to have r/x permissions too.

SELinux doesn't have anything to do with this! ACL and SELinux are separate extensions to the basic security model that Linux offers.

I have (work/home) servers running with basic + ACL, basic + SELInux and basic + ACL + SELinix models. All do exactly what they are supposed to do.

Shame on your senior colleague

EDIT: Here are 2 ACL related links:
- Chapter 8. Access Control Lists
- POSIX Access Control Lists on Linux

devUnix · 11-18-2013, 04:25 PM

Quote:

Originally Posted by druuna

SELinux doesn't have anything to do with this! ACL and SELinux are separate extensions to the basic security model that Linux offers.

I have (work/home) servers running with basic + ACL, basic + SELInux and basic + ACL + SELinix models. All do exactly what they are supposed to do.

Shame on your senior colleague

Haha!!! Thanks for the explanation!

By the way, that senior colleague asked me to have Windows Support create an addition group containing only those two users/members who need access to the directory, and then I am to add that group to the group part of the directory. I had to follow his advice because I was/am not sure of the following:

If I enabled ACL on the disk /dev/sda3 which is mounted on "/", could other apps be affected anyhow? The server is live and is a production one.

druuna · 11-19-2013, 02:19 AM

Quote:

Originally Posted by devUnix

I was/am not sure of the following: If I enabled ACL on the disk /dev/sda3 which is mounted on "/", could other apps be affected anyhow? The server is live and is a production one.

Seen from acl: Nope, activating acl doesn't affect the system. The only thing this does is give you the possibility to set acl's and the current permissions stay the same.

However: You do need to remount the root partition to activate the option and setting the wrong acl permissions after that might affect the system.

If at all possible try all this on a non-production server first and after that works pick a good moment to implement this on the production server(s).