How are group permissions assigned privileges?

[CaffeineAddict]

Recently I was pondering one question that's remnant knowledge from when I used Windows...

On Windows when you create a new group you can assign what permissions that group has,
note that I'm not talking about file system permissions and ownership of files and directories but other permissions such as privileges to do things which standard users e.g. not root can do.

For instance on Linux we have sudo group and user primary group.
User primary group does not have same privileges as sudo group, yet both have the concept of file system permissions and file/directory ownership.

So my questions are:
1.) when a new user group is created, how do we assign what privileges that group has?
2.) How to view privileges of existing groups and how to modify them?
3.) What determines default privileges when a new group is created?

 

[dos2unix]

I would say the owners of the file/directory is what determines who can access/run it.

chown :groupname filename

or

chmod g+rwx filename

Of course ls -l will show you the user/group that owns/has permissions to that file/directory.

 

[CaffeineAddict]

@dos2unix

note that I'm not talking about file system permissions and ownership of files and directories but other permissions such as privileges to do things which standard users e.g. not root can do.

I know about chown, chmod etc. but this are file system permissions, what I want to know is system permissions, such as:
group privilege to modify network configurations
group privilege to modify configuration X,Y or Z on system etc.

Does such concept exist on Linux?

 

[osprey]

@dos2unix


I know about chown, chmod etc. but this are file system permissions, what I want to know is system permissions, such as:
group privilege to modify network configurations
group privilege to modify configuration X,Y or Z on system etc.

Does such concept exist on Linux?

Does the wheel group have any relevance to your questions? See here: https://www.baeldung.com/linux/wheel-group
There's a hint in point 2.2 about specialised group permissions.

 

[CaffeineAddict]

There's a hint in point 2.2 about specialised group permissions.

The article doesn't explain the details but it hints that such concept is possible with the help of PAM modules and ACL's.

This is not same thing as on Windows but with proper configuration it should be possible to create a group with special privileges and authentication mechanism to certain files and directories such as web server directory or files/directories of some other service.

However manipulation of a service itself e.g. daemon is still something that only root user can do, and can't be manipulated with ACL's.
Maybe this can be achieved with certain PAM modules but I suspect that's possible.

Will need to read more about PAM modules and config to come to final conclusion.

 

[Trml]

However manipulation of a service itself e.g. daemon is still something that only root user can do, and can't be manipulated with ACL's.
Maybe this can be achieved with certain PAM modules but I suspect that's possible.

As you have implicitly concluded, the PAM modules are dealing with the authentication only. There are exceptions (pam modules for specific purposes), but in general they don't define the granted authorization. For the latter there are a bunch of mechanisms, both in the kernel (e.g. cgroups, capabilities) and the distro (daemon/application settings) you run (e.g. polkit, dbus). (there are man-pages for all of the acronyms).
A simple example: when you log into your desktop, it arrives with distro-/pre-bundled authorizations, e.g. to reboot the machine as a user or automatically mount usb storage. For a share of the popular authorizations, the desktop may enable to tweak them via settings or at least via a backend like Gnome's gsettings. When you log into your machine via ssh, these local-user/desktop rules don't apply per se, i.e. you won't be able to ssh-reboot the machine without sudo. In both cases (local/ssh), there is PAM doing the authentication, but not controlling the authorization. To get a better understanding it may be best to focus on a specific task, have a look which software is operating/controlling it (e.g. udev for usb) and then look for its default configuration.