Trying to set tight permissions on my future NAS.
The essential on what I have:
TrueNAS NFS storage <- mounted via NFS -> Proxmox VE Host <-> Debian 12 VM
That’s all fine and so on.
My little Debian VM:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 A5D7-88E3 505.1M 1% /boot/efi
└─sda2 ext4 1.0 3c43a477-51fd-425b-aee8-a6e75224f781 48.5G 16% /
sdb
└─sdb1 ext4 1.0 media e3e0eac5-806a-44e9-a0e9-07fb99a18281 933.2G 0% /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281
sdc
└─sdc1 ext4 1.0 nas 0f3a3d74-901d-4243-b20b-59210c1cee18 46.4G 0% /srv/dev-disk-by-uuid-0f3a3d74-901d-4243-b20b-59210c1cee18
sdd
└─sdd1 ext4 1.0 backup fbe21b9f-2339-4223-ac7e-00e75374fc32 46.4G 0% /srv/dev-disk-by-uuid-fbe21b9f-2339-4223-ac7e-00e75374fc32
sr0
Background:
- media = media library for Jellyfin
- nas = small (future) file server for my PC running Windows
- backup = used to store backups of various services like Firewall backups with SFTP etc.
The storage on the debian VM will be mounted by a NUC running bare metal Debian due to hardware acceleration. The proxmox host is unable to do it due to it also being a NUC. But I like the flexibility I will soon have because I can just nuke my bare-metal NUC without loosing any data.
Anyway my real problem is with permissions on my media drive.
My permissions right now are as following:
1. /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281# ls -l media
drwxrwxr-x 3 nobody nogroup 4096 Oct 12 20:45 media
2. /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media# ls -l data
drwxrwsr-x+ 6 mediaU serviceG 4096 Oct 13 00:21 data
3. /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# ls -l *
drwxrwsr-x+ 7 mediaU serviceG 4096 Oct 13 00:21 media
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 recycle_bin
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 torrents
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 usenet
4. /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data/media# ls -l *
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 anime
drwxrwsr-x+ 3 mediaU serviceG 4096 Oct 13 00:22 movie
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 music
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 soundtrack
drwxrwsr-x+ 2 mediaU serviceG 4096 Oct 13 00:21 tv
Current directory tree:
srv-dev-disk-by-uuid-XXX/
└── media
└── data
├── media
│ ├── anime
│ ├── movie
│ ├── music
│ ├── soundtrack
│ └── tv
├── recycle_bin
├── torrents
└── usenet
What I am trying is:
- Docker host mounts
/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/mediavia NFS - The docker containers should only be able to access the the
datadirectory inside it (2.ls -l) as mediaU:serviceG - In addition I wanna access, modify and move files with my windows user without being part of the service group. Because of this I have setup SGID and ACL on the
/media/data/mediafolder. The ACL was set recursive as follows:
/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# getfacl media/
# file: media/
# owner: mediaU
# group: serviceG
# flags: -s-
user::rwx
group::rwx
group:extUserG:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:extUserG:rwx
default:mask::rwx
default:other::r-x
So far so good. mediaU:serviceG has RWX permissions (2775).
My user is part of the group extUserG also with 775 permission.
My issue and how I tested it under the root user executing commands via su:
- Works:
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# su mediaU -c 'mkdir dir-mediaU' - Doesn’t work:
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# su appoxo -c 'mkdir dir-extUserG' mkdir: cannot create directory ‘dir-extUserG’: Permission denied
BUT if I enter one level deeper inside the freshly created dir-mediaU folder I am able to create files with my personal account:
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# cd dir-mediaU/
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data/dir-mediaU# su appoxo -c 'mkdir dir-extUserG'
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data/dir-mediaU# ls -l
total 4
drwxrwsr-x+ 2 appoxo serviceG 4096 Oct 13 00:45 dir-extUserG
root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data/dir-mediaU# getfacl dir-extUserG/
# file: dir-extUserG/
# owner: appoxo
# group: serviceG
# flags: -s-
user::rwx
group::rwx
group:extUserG:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:extUserG:rwx
default:mask::rwx
default:other::r-x
So dear Lemmy Community:
Have I done something wrong in my setup or thinking? I have no problem as it is right now but I am sure it will be annoying to troubleshoot in the future so might as well fix it while still setting it up.
Thanks in advance for helping slowly escaping the windows world :)
You must log in or # to comment.
What is the acl permissions on the media/data folder? That is what the dir-mediaU would inherit.
I think we need the output of: root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media# getfacl data
Thank you for responding and helping!
# tree: ├── dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281 │ └── media │ └── data │ ├── media │ ├── recycle_bin │ ├── test │ ├── torrents │ └── usenetI assume you mean the actual
mediadirectory in level 3 on the tree?/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# getfacl media/ # file: media/ # owner: mediaU # group: serviceG # flags: -s- user::rwx group::rwx group:extUserG:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:extUserG:rwx default:mask::rwx default:other::r-xJust in case the
datafolder in level 2 as well:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media# getfacl data/ # file: data/ # owner: mediaU # group: serviceG # flags: -s- user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:group:extUserG:rwx default:mask::rwx default:other::r-xI haven’t done much dicking around with Posix ACLs.
And I’m not completely sure what you want to do, even after looking at your comment a couple of times.
If the issue is that you want this operation to succeed:
Doesn’t work: root@NAS01:/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data# su appoxo -c ‘mkdir dir-extUserG’ mkdir: cannot create directory ‘dir-extUserG’: Permission denied
Then it’s presumably that the permissions on
media/dataaren’t what you want.If I understand correctly:
-
You have a user appoxo which belongs to the group extUserG. That is, if you type
groupsas that user, then you see “extUserG” listed. -
You want this user to have write permissions to /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media/data.
You can see from your
getfacl data/command that the data directory doesn’t grant write privileges to extUserG. It has a default ACL entry granting write privileges, so things created in that directory will inherit an ACL entry. Butdataitself doesn’t have an ACL entry granting write privleges to extUserG.You want
datato have this ACL entry when you rungetfacl data:group:extUserG:rwxas well as the default ACL entry:
default:group:extUserG:rwxRight now, it only has the default ACL entry:
default:group:extUserG:rwxIf you run
sudo setfacl -m g:extUserG:rwx datain the top-levelmediadirectory, then that should add the ACL entry, and I’d expect that user appoxo would subsequently be able to create and modify files and directories directly insidedata.Note that I’m not saying that this is necessarily sufficiently-restrictive to do the other things you want, like constraining your containers or whatnot, so don’t expect me not mentioning that to be a thumbs-up there – I mean, we can’t see the ACL on the top-level
media/, so no way to confirm that.One possible concern: I think that a process with serviceG in its list of groups – such as what I expect your docker containers would be – can remove the
extUserGACL entry. That is, they could prevent appoxo from being able to fiddle with files that they have created. That may or may not be a problem for you. Appoxo can ultimately re-add that ACL entry to any thing underdatafrom which the ACL entry is removed, as long as they have write access todata(which should be the case after you run the command above I mentioned. But appoxo doesn’t quite, as things stand, act like “root” for the whole directory hierarchy, doesn’t just bypass permissions.sudo setfacl -m g:extUserG:rwx data
THANK YOU for solving the issue.
Can you tell me what went wrong during setting the acl the first time?
Because if my memory serves me right (it was well beyond 11pm) that’s the command I had typed in.
I believe it was/srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media# sudo setfacl -d -m g:extUserG:rwx dataAlso why do I need both
default:group:extUserG:rwxandgroup:extUserG:rwxto be able to write in themedia/datadirectory? Shouldn’t the first one be sufficient enough?Because if my memory serves me right (it was well beyond 11pm) that’s the command I had typed in.
I believe it was /srv/dev-disk-by-uuid-e3e0eac5-806a-44e9-a0e9-07fb99a18281/media# sudo setfacl -d -m g:extUserG:rwx data
You probably did exactly that.
I expect that the -d there just makes the command set a default ACL entry rather than a regular ACL entry, doesn’t set both.
tests
Yeah. You need two commands if you want both a default and regular ACL entry.
You want a default ACL entry and a regular ACL entry on
data.The regular ACL entry affects items directly inside
data.The default ACL entry causes items that you create inside
datato have that ACL. It doesn’t both do that and act as a regular ACL entry fordata.Also why do I need both default:group:extUserG:rwx and group:extUserG:rwx to be able to write in the media/data directory? Shouldn’t the first one be sufficient enough?
Nope. Looks like the default ACL entry won’t actually affect permission checking itself. Though like I said, I’ve done virtually nothing with Posix ACLs in the past, so that’s from a brief glance at the docs and a quick test.
Yeah. You need two commands if you want both a default and regular ACL entry.
You want a default ACL entry and a regular ACL entry on data.
The regular ACL entry affects items directly inside data.
The default ACL entry causes items that you create inside data to have that ACL. It doesn’t both do that and act as a regular ACL entry for data.
I think that’s the magic spell.
So assuming I didn’t want to set the regular ACL and the default ACL I would need to set the ACL not on
/srv/disk-uid/media/databut instead on/srv/disk-uid/media/and would achieve essentially the same result?Though like I said, I’ve done virtually nothing with Posix ACLs in the past, so that’s from a brief glance at the docs and a quick test.
I would say this really doesn’t matter that much. I assume you are using linux way longer and more intensely than me and experience will help with reading the docs. I tried the same but the manpage is a bit difficult to read for me and the guides, forum posts etc. are sometimes over 10 years old and/or doesn’t apply to my goal (or my search-fu failed me).
Classic example of someone from 10 years ago: https://www.linuxquestions.org/questions/linux-newbie-8/acl-vs-default-acl-4175478547/And sometimes you just need a colleague or rubber duck to help you get out of a mind spiral :D
Again: Thank you very much. If you have a paypal adress and willing to pm it to me I’d like to tip you. Because unlike on Reddit, Lemmy is actually helpful.
If you don’t prefer that, maybe a OSS-project I can send it to? :)So assuming I didn’t want to set the regular ACL and the default ACL I would need to set the ACL not on /srv/disk-uid/media/data but instead on /srv/disk-uid/media/ and would achieve essentially the same result?
If you set the default ACL entry on
/srv/disk-uid/media/prior to creatingdatain that directory, then when you createddata,datawould get a default ACL entry and a regular ACL entry. That’s what you have now, and probably what you want.Though as things stand, I have no idea what the ACL on
/srv/disk-uid/media/is, so I can’t promise you that it’d be identical. If you also set a regular ACL entry on that directory in reality, then it wouldn’t look like your hypothetical scenario.or my search-fu failed me
I think that it’s mostly that a lot of Linux users don’t wind up using the ACL system, as the traditional Unix permissions system does all they want, and so they don’t need to even touch ACLs. So not a lot of stuff out there talking about it. If you’re using Windows or VMS or something, then coming into contact with ACLs isn’t optional; if you’re doing file permissions, you’re doing ACLs.
Though like I said, I’ve done virtually nothing with Posix ACLs in the past, so that’s from a brief glance at the docs and a quick test.
I would say this really doesn’t matter that much.
I’m just warning about taking it authoritatively. I’ve got relevant background, but not specifically on Posix ACLs. What you got is “I tested it for under a minute and glanced very briefly at docs, and have very sporadically used them.”
If you don’t prefer that, maybe a OSS-project I can send it to? :)
Nah, but thanks. Do what you want with your coins!
That’s what I get for falling asleep. Looks like you guys nailed it. I just saw the first reply this morning, and was going to say exactly what you did. There was a default group entry and no actual group entry on the media/data folder. Appoxo, with no actual group entry for extUserG it wouldn’t have permission in that folder, but any folder created in that folder would inherit the ‘default group’ permission and would have group permission for extUserG. :)
-
