Re: [PLUG] Setting proper user and group permissions on a directory

I guess my understanding is flawed ....

So, in order to test that members of a certain group ("TitleCompanies") have rwx access into a directory tree ("/TitleDocuments"), I did this:

[root@phaserv1:/] $ setfacl -R -d --set=g:TitleCompanies:rwx /TitleDocuments/
[root@phaserv1:/TitleDocuments] $ getfacl --access -d /TitleDocuments
getfacl: Removing leading '/' from absolute path names
# file: TitleDocuments
# owner: root
# group: root
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:TitleCompanies:rwx
default:mask::rwx
default:other::r-x

So far, so good, right? I should be all set for the future, any member of the group "TitleCompanies" should be able to access any directory/file create in this tree, by any user.

(That's the goal)

Then, in testing, (as root - yes, yes, I know) I created a sub-directory, and put a file into it:

[root@phaserv1:/TitleDocuments] $ mkdir TestDir02-by-root
[root@phaserv1:/TitleDocuments] $ cd TestDir02-by-root/
[root@phaserv1:/TitleDocuments/TestDir02-by-root] $ ls -la >This-is-a-file-by-root

Checking permissions ...

[root@phaserv1:/TitleDocuments] $ getfacl --access -d /TitleDocuments/TestDir02-by-root/
getfacl: Removing leading '/' from absolute path names
# file: TitleDocuments/TestDir02-by-root
# owner: root
# group: root
user::rwx
group::rwx
group:TitleCompanies:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:TitleCompanies:rwx
default:mask::rwx
default:other::r-x

[root@phaserv1:/TitleDocuments] $ getfacl --access /TitleDocuments/TestDir02-by-root/This-is-a-file-by-root
getfacl: Removing leading '/' from absolute path names
# file: TitleDocuments/TestDir02-by-root/This-is-a-file-by-root
# owner: root
# group: root
user::rw-
group::rwx #effective:rw-
group:TitleCompanies:rwx #effective:rw-
mask::rw-

So then, I connected as my user would, from a Windows machine running WinSCP. This user is a member of that special group "TitleCompanies".

(the idea is that the user would copy that whole portion of the directory tree over to her storage)

She can get into that "TestDir02" directly, and into that file "This-is-a-file-by-root", as expected, since she has group permissions. All good so far.

But what she can't do is delete it ... and I don't understand why, since that group should have rights to read/write/delete any file in the "/TitleDocuments" tree.

What am I missing here?

She doesn't have any problem deleting files created by users other than root. Why aren't the group permissions fully working here, as I am expecting them to?

(I'm probably expecting wrongly, I just don't know *why* I'm wrong. I'm hoping someone can tell me ...)

Just because the file was created by root shouldn't matter, since the group has permissions ...

Thanks for any help clearing that up ...

On Fri, Jan 3, 2025 at 3:11 PM Mike Leone <turgon@mike-leone.com> wrote:

On Thu, Jan 2, 2025 at 3:00 PM Mike Leone <turgon@mike-leone.com> wrote:
$ setfacl -d --set g:TitleCompanies:rwx /TitleDocuments/
setfacl: /TitleDocuments: Operation not supported

$ cat /etc/fstab
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup00/LogVol01 swap swap defaults 0 0

So I followed this:
https://www.ucartz.com/clients/knowledgebase/1485/Solution-for-setfacl-Operation-not-supported-in-Linux-Servers.html

and issued this:
tune2fs -o acl /dev/VolGroup00/LogVol00

Looks like it worked?

[root@phaserv1:~] $ tune2fs -l /dev/VolGroup00/LogVol00 | grep 'mount option'
Default mount options: acl
[root@phaserv1:~] $

Then, just to be extra sure, I rebooted. (you're supposed to just re-mount, but I figured why not, it hadn't been rebooted in a number of months ...)

Looks like the change took ...

[root@phaserv1:~] $ tune2fs -l /dev/VolGroup00/LogVol00 | grep 'mount option'
Default mount options: acl
[root@phaserv1:~] $
[root@phaserv1:/TitleDocuments] $ mkdir TestDir
[root@phaserv1:/TitleDocuments] $ setfacl -d --set=g:TitleCompanies:rwx /TitleDocuments/TestDir
[root@phaserv1:/TitleDocuments] $ cd TestDir/
[root@phaserv1:/TitleDocuments/TestDir] $ mkdir TestDir2
[root@phaserv1:/TitleDocuments/TestDir] $ getfacl TestDir2
# file: TestDir2
# owner: root
# group: root
user::rwx
group::r-x
group:TitleCompanies:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:TitleCompanies:rwx
default:mask::rwx
default:other::r-x

So it looks like it worked, I guess - I see my group in the list for the new directory I created within the directory I created, without having to explicitly add the group perms. Which I guess means that if the vendor creates new directories and populates them, all the files and directories will have my group in the perms, meaning my employees who log in as members of that group will have access to the files and directories.

Thanks for the assist! I'll test more next week, that's enough for today, especially with the snow coming. LOL