[solved] Permission managment for root and other admin users.

Elizabeth · 2025-04-11 13:35:55

Recently I've been reading the Archwiki security page , particularly the user file permission and user setup sections, and I've been wondering how I could set up file permissions and administeator user access to files owned by root without simulatensouly being too permissive.

This problem arose from me when I first isntalled arch and, follwing the security page, set the umask 077. Later, I also set the umask override to 022 (eather unwittingly) for quality of life reasons such as allowing zsh shell autocompletion to work on directories made with sudo that arent security critical.

Unfortunately, I failed to realise that this would make anything I install with pacman trough sudo have those same file permissions, resulting in a Frankenstein patchwork of file permissions on files owned by root.

Here, I'm wondering if there is a way to make it so any users in the wheel / adm groups have read access to files not explicitly set as "root only" (0X00 perms). Alternatively, other solutions would be very welcome.
Additionally, I'm writing this to check whether this is even a good idea, given that I am not by any means an expert on security, and I do not want to make potentially compromising changes to my system.

Last edited by Elizabeth (2025-04-12 22:53:40)

Allan · 2025-04-11 14:19:51

Elizabeth wrote:

Unfortunately, I failed to realise that this would make anything I install with pacman trough sudo have those same file permissions, resulting in a Frankenstein patchwork of file permissions on files owned by root.

Pacman handles umasks correctly to ensure that file permissions are as set inside the package.

Elizabeth · 2025-04-11 14:31:13

Allan wrote:

Pacman handles umasks correctly to ensure that file permissions are as set inside the package.

My bad then.

That should solve the largest part of my problems. The other part I can solve by setting the umask to 027 instead of 077 (as dicussed in the archwiki umask article iirc), and manually change groups ownership on files I regularly access that arent also security critical. And if I'm making a directory from scratch I can set the SGID bye to make it so I don't need to constantly update the files' permissions.

Though I do still want to check if this is secure to do, because I do know SUID and GUID bits are very easy to mess up, but not exactly how not to mess them up.

seth · 2025-04-11 23:09:44

There's no generic answer - the thread model is context specific (who's access are you concerned about) and specific (individual files and paths will reuqire individual access restrictions - "who has a business to see or alter this?")
The surprising recognition will be that the indivdual you should have been concerned about to access paths was… you.
Ie. next to deliberate attacks, you screwing up is part of what those restrictions combat.

For directories, traversal restrictions (no execution bit) can be seen as part of multi-layered security. Maybe it's not a problem that joeschmoe can enter this directory, but if they can't and you forgot to properly secure a path inside it, the outer restriction can safe you ("can" because you're not supposed to rely on that to then learn that there was an exploitable path pollution bug)

What's really often a surprise is that unless a file is chattr's immutable or the directories sticky bit (restricted deletion) is set, if you've writing access to a directory you can delete a file you don't own (even if you cannot write the file itself!) and replace it with your own version - you effectively edited the file.

SUID should™ only be relevant on executable files (ie. be inert on directories), where the surprise is that execution rights can also come via ACL and will still apply the SUID
The other surprise is what executables actually can provide you with a root shell - a somewhat common fallacy is/was/is that SUID on "less" is convenient and (regardless of privacy concerns) cannot harm… right? RIGHT??

The most dangerous aspect of the directory SGID is that you can forget that it's there.
Same goes for the umask. There're two scenarios after creating a directory:
1. cd foo "ah, fuck." sudo chmod g+rx foo; cd foo
2. "Oh no! Why was that accessible to unprivileged users??? … Fuck!"

So the question is whether you're more concerned about the period or the exclamation point after the inevitable "fuck" - is scenario #1 so frequent for you that it's worth the ever so remote chance of scenario #2?

manually change groups ownership on files I regularly access that arent also security critical

Why have uncritical files access restrictions?
And are you maybe looking for "man sudoedit" ?

Elizabeth · 2025-04-12 22:52:11

seth wrote:

There's no generic answer - the thread model is context specific (who's access are you concerned about) and specific (individual files and paths will reuqire individual access restrictions - "who has a business to see or alter this?")
The surprising recognition will be that the indivdual you should have been concerned about to access paths was… you.
Ie. next to deliberate attacks, you screwing up is part of what those restrictions combat.

For directories, traversal restrictions (no execution bit) can be seen as part of multi-layered security. Maybe it's not a problem that joeschmoe can enter this directory, but if they can't and you forgot to properly secure a path inside it, the outer restriction can safe you ("can" because you're not supposed to rely on that to then learn that there was an exploitable path pollution bug)
What's really often a surprise is that unless a file is chattr's immutable or the directories sticky bit (restricted deletion) is set, if you've writing access to a directory you can delete a file you don't own (even if you cannot write the file itself!) and replace it with your own version - you effectively edited the file.
SUID should™ only be relevant on executable files (ie. be inert on directories), where the surprise is that execution rights can also come via ACL and will still apply the SUID
The other surprise is what executables actually can provide you with a root shell - a somewhat common fallacy is/was/is that SUID on "less" is convenient and (regardless of privacy concerns) cannot harm… right? RIGHT??
The most dangerous aspect of the directory SGID is that you can forget that it's there.
Same goes for the umask. There're two scenarios after creating a directory:
1. cd foo "ah, fuck." sudo chmod g+rx foo; cd foo
2. "Oh no! Why was that accessible to unprivileged users??? … Fuck!"
So the question is whether you're more concerned about the period or the exclamation point after the inevitable "fuck" - is scenario #1 so frequent for you that it's worth the ever so remote chance of scenario #2?
manually change groups ownership on files I regularly access that arent also security critical
Why have uncritical files access restrictions?
And are you maybe looking for "man sudoedit" ?

Your saying that made me realise that yes, traversal restrictions are so rare on my system that it's just not worth it removing them.

Thank you for the added info about SUID and SGID (in)security, and thank you for showing me the sudoedit command!

Marking as solved. (Damn you Occam's razer)

Last edited by Elizabeth (2025-04-12 22:53:26)

Arch Linux

#1 2025-04-11 13:35:55

[solved] Permission managment for root and other admin users.

#2 2025-04-11 14:19:51

Re: [solved] Permission managment for root and other admin users.

#3 2025-04-11 14:31:13

Re: [solved] Permission managment for root and other admin users.

#4 2025-04-11 23:09:44

Re: [solved] Permission managment for root and other admin users.

#5 2025-04-12 22:52:11

Re: [solved] Permission managment for root and other admin users.

Board footer