A good start is using something like sudo rather than logging in as root.
sudo gives your command root permission when it runs. That way you can delete the password from the root account and it can’t be logged in with. sudo will ask for YOUR password and then check if you have permissions to elevate your command to root level.
In a simple setup, you can just use for anything you would normally do as root.
This can protect you from mistakes too, when running commands that you’ve mistyped. For example, if you want to do “rm -rf ./*” to delete all files in the current directory, but you forget the dot (period); if you’re at a root prompt, you just deleted your entire filesystem. If you’re not, then you get a permission error.
One issue is trying to create a user to run services under, but not knowing how to give it permission to access what it needs (while also not entirely sure what it should/shouldn’t have permissions for).
Or just generally managing file permissions. I understand using chmod in a very basic capacity with a few letter arguments like +r, but then you toss in numbers (chmod 777, wut?) and I get lost.
In addition to what other posters said, some distros allow you to add a user to the “sudo” group (as a secondary group assignment; don’t make it their primary) to allow them sudo access.
The /etc/sudoers file is what you’d need to edit, and you’d use the visudo command to edit it.
chmod is indeed used for file permissions, but you can also use SELinux or AppArmor for more access/role/action based permissions (aka Mandatory Access Controls) instead of just limiting yourself to file permissions (aka Discretionary Access Control). There’s also udev rules (for device/sysfs access) and PAM (Pluggable Authentication Modules). Then there’s cgroups and namespaces for process limits and sandboxing. Really depends on what you’re trying to achieve.
But is there any reason why you’re looking into micromanaging service permissions? Most users, or even power users wouldn’t need to touch that stuff at all.
If it’s in a corporate environment, you’d already be running something like SELinux or similar and you’d apply a baseline security profile that meets various compliance specs. Very rarely would you have to mess with permissions of a service.
If this is for personal stuff, you’d just make use of multiple user accounts (if it’s a multi-user system), or just sandboxing (containers, flatpak etc) to run untrustworthy stuff like web browsers. None of this stuff would require you to touch chmod.
But is there any reason why you’re looking into micromanaging service permissions?
Because I don’t know any better, having very little base knowledge of linux.
The thought process here was that services like nginx should be running under a separate user from root and your main daily user account, only having access to the files it actually needs, but not really knowing how to achieve that. I know genuinely nothing about linux user management and feel a bit overwhelmed trying to figure out where to start :/ (especially comming from the all graphical UI experience of Windows)
Chmod is/was the only tool I’ve known about for managing permissions. I end up running stuff as root in my experimentations because I randomly run into permissions errors, but don’t know how to solve them, particularly without creating more problems for other processes.
I’m using Debian as a first Linux desktop experience; previously I’ve done some experimenting with rpis managed via ssh, mostly to run pihole, that’s about it. The rest has been windows where I was familiar.
nginx only runs the master process as root, but the actual worker processes already run under a low-privileged account called http. If you want to run the master process as well as non-root, you can follow the instructions here: https://wiki.archlinux.org/title/nginx#Running_unprivileged_using_systemd
To restrict access to files, you’d be editing the nginx config file, you can read on how to do that in the nginx documentation, or check ServerFault etc.
But the modern Linux world revolves around containers. There’s an official Docker image for nginx that you could use if you’d like, and that’d make it a much more secure - and portable option.
Also, I’d recommend checking the Arch Wiki first for anything Linux related - the wealth of knowledge and documentation there is unmatched, and is useful even if you’re not running Arch.
Side question:
Know a good place I can learn linux user/group/permission management?
I don’t understand it well enough so I do a stupid amount of things as root…
A good start is using something like sudo rather than logging in as root.
sudo gives your command root permission when it runs. That way you can delete the password from the root account and it can’t be logged in with. sudo will ask for YOUR password and then check if you have permissions to elevate your command to root level.
In a simple setup, you can just use for anything you would normally do as root.
This can protect you from mistakes too, when running commands that you’ve mistyped. For example, if you want to do “rm -rf ./*” to delete all files in the current directory, but you forget the dot (period); if you’re at a root prompt, you just deleted your entire filesystem. If you’re not, then you get a permission error.
How do I manage what users can use sudo?
One issue is trying to create a user to run services under, but not knowing how to give it permission to access what it needs (while also not entirely sure what it should/shouldn’t have permissions for).
Or just generally managing file permissions. I understand using chmod in a very basic capacity with a few letter arguments like +r, but then you toss in numbers (chmod 777, wut?) and I get lost.
In addition to what other posters said, some distros allow you to add a user to the “sudo” group (as a secondary group assignment; don’t make it their primary) to allow them sudo access.
Edit your /ect/sudoers file using visudo
The
/etc/sudoersfile is what you’d need to edit, and you’d use thevisudocommand to edit it.chmodis indeed used for file permissions, but you can also use SELinux or AppArmor for more access/role/action based permissions (aka Mandatory Access Controls) instead of just limiting yourself to file permissions (aka Discretionary Access Control). There’s also udev rules (for device/sysfs access) and PAM (Pluggable Authentication Modules). Then there’s cgroups and namespaces for process limits and sandboxing. Really depends on what you’re trying to achieve.But is there any reason why you’re looking into micromanaging service permissions? Most users, or even power users wouldn’t need to touch that stuff at all.
If it’s in a corporate environment, you’d already be running something like SELinux or similar and you’d apply a baseline security profile that meets various compliance specs. Very rarely would you have to mess with permissions of a service.
If this is for personal stuff, you’d just make use of multiple user accounts (if it’s a multi-user system), or just sandboxing (containers, flatpak etc) to run untrustworthy stuff like web browsers. None of this stuff would require you to touch chmod.
Because I don’t know any better, having very little base knowledge of linux.
The thought process here was that services like nginx should be running under a separate user from root and your main daily user account, only having access to the files it actually needs, but not really knowing how to achieve that. I know genuinely nothing about linux user management and feel a bit overwhelmed trying to figure out where to start :/ (especially comming from the all graphical UI experience of Windows)
Chmod is/was the only tool I’ve known about for managing permissions. I end up running stuff as root in my experimentations because I randomly run into permissions errors, but don’t know how to solve them, particularly without creating more problems for other processes.
I’m using Debian as a first Linux desktop experience; previously I’ve done some experimenting with rpis managed via ssh, mostly to run pihole, that’s about it. The rest has been windows where I was familiar.
Okay so that’s different.
nginx only runs the master process as root, but the actual worker processes already run under a low-privileged account called
http. If you want to run the master process as well as non-root, you can follow the instructions here: https://wiki.archlinux.org/title/nginx#Running_unprivileged_using_systemdTo restrict access to files, you’d be editing the nginx config file, you can read on how to do that in the nginx documentation, or check ServerFault etc.
But the modern Linux world revolves around containers. There’s an official Docker image for nginx that you could use if you’d like, and that’d make it a much more secure - and portable option.
Also, I’d recommend checking the Arch Wiki first for anything Linux related - the wealth of knowledge and documentation there is unmatched, and is useful even if you’re not running Arch.
Thanks for your help m8, I appreciate it.
I’ll have to do some more reading once I’ve got some time.