In SB, you are unable to add yourself to most of the groups without hacks:
It was suggested to use Polkit instead.
@siosm How do I do that exactly?
Did you read the linked suggestion?
Sorry?
@computersavvy If you read those issues on github, you will see none of them are finished.
So I tried to apply existing workaround to SB, but that was rejected above.
Is it even possible to use Polkit for these purposes?
I have very little experience with it, so need help.
On atomic systems, you can only join groups in /etc/group.
Optional system groups are available in /usr/lib/group.
To add yourself to an external group you must explicitly (AT YOUR OWN RISK) copy the group you wish to join from the /usr/lib/group to the /etc/group. Then you can join such group.
Example:
Add the groups to /etc/group
grep -E '^disk:' /usr/lib/group | sudo tee -a /etc/group
grep -E '^dialout:' /usr/lib/group | sudo tee -a /etc/group
Append new groups
sudo usermod -aG disk,dialout $USER
Thanks, but this is what suggested in Troubleshooting already.
What I’m interested of is the possibility to use Polkit for this purpose.
If such possibility is absent or unknown, `usermod -a -G disk username` fails · Issue #657 · fedora-silverblue/issue-tracker · GitHub should be reopened.
I don’t know why that was suggested. The polkit is primarily for controlling access to dbus services. For example, if you run systemctl stop someservice, the polkit is checked to see if you are allowed to run this command, and if need be, ask for a password.
What is the purpose of joining those groups?
The permissions of /dev/ttyS* are as follows:
crw-rw----. 1 root dialout 4, 64 Jun 8 10:38 /dev/ttyS0
This means, the user “root” can read and write to this device, and members of the group “dialout” can also read and write. Everybody else can’t do anything with this device.
Are you not a superuser on the operating system? A superuser has access to this and every file on the system.
Are you trying to bypass the password prompt?
You can use polkit for other operations. It does not have to be DBus services.
I would appreciate if you help to solve the topic then.
Sure, what have you tried already? A quick search gives me the two guides with examples:
Sure I looked at the common guides.
They are not helpful regarding to the topic.
What I learned so far Polkit is not useful here, and can’t substitute adding a user to the groups in question.
Do you have concrete solution in mind?
I don’t have to do anything of such using systemd-homed… Although I have to (selinux) relabel the homedir before 1st login.
Do you mind explaining how you are going to access ttyS*? I could imagine you have a program which needs to talk to a device connected with a serial rs232 cable.
Polkit doesn’t grant priveleges. It just combines various inputs (the action to do, the one performing the action, the one requesting the action, and the related user-group ecosystem around it) and emits to the doer whether to do, not to do.
It’s a decision-making engine, for access control.
Eg.: systemctl start virtqemud.socket: systemctl just has to signal to the D-Bus interface of systemd; But the interface is hooked up to use polkit, ask if the user requesting the particular operation is allowed to do so… then polkit issues a password prompt, which when returns successfully, allows the operation to proceed.
It just knows the “actions” to do, the “users” and “groups” are generic attributes in XML/JS, and “rules” which tie all these together.
Programs explicitly voluntarily ask polkit if a requested action is “allowed” under given circumstances. Like systemd, udisks, etc…
The idea that polkit can escalate priveleges or just provide access to anything, is wrong.
For /dev/ttyS*, you need to:
- Make sure that the devices are accessible to a particular group; Already done.
- Add all users needing access to
/dev/ttyS*to that group, in this case thedialoutgroup (See below how to do so).
To add user to group:
- For users under systemd-homed,
homectl update $USER -G ${EXISTING_GROUPS_COMMA_SEPARATED},dialout - For users under the “traditional”
/etc/{passwd,shadow}files,grep -E '^dialout' /usr/lib/group | sudo tee -a /etc/groupto get the group record modifiable.- Normally add yourself via
usermod -aG dialout $USER
Have you tried creating an action and corresponding rules to allow users to run the command that you want to run with special access to those devices?
Run the command through? pkexec? run0?
Let me repeat that polkit runs under the polkit restricted user itself, it can’t do what you are asking for… Some other daemon could do that, hooking into polkit for access control, but polkit itself can’t do anything other than raw decisions… “It’s fine to do that” “Request isn’t authorized, don’t do that” But the actual work is to be done by something else.
It is the server which asks polkit if a requested action is allow or not. The server already have the privileges, but it can ask polkit if it has to restrict itself if the client is not authorized to ask the server to some specific action.