You are not logged in.
Pages: 1
I would like to understand why adding my users to 'storage' does not allow them to mount (or write to storage), why adding them to 'power' does not allow them to shutdown, real-time threads are not available to members of 'audio', etc.
I understand there are workarounds involving sudo (for enabling shutdown), but that does not explain why on earth the system does not care that I have enabled the rights for these users.
This does not appear to be a matter of misconfiguration, as it has been true of every single Arch install I have ever done. /etc/group is simply ignored, the settings there are not respected. Can someone please explain why this is?
I have hal, udev, dbus all in the daemons array in /etc/rc.conf . I've looked at the /etc/dbus-1/hal.conf rules and it says that my users should be able to do these things when they belong to these groups. What is the point of this security model if it is not at all respected?
[Edit: s:FDI:/etc/dbus-1/hal.conf ]
Last edited by jceasless (2010-09-18 21:31:30)
Offline
HAL is deprecated, perhaps that's your issue, that nothing actually uses it anymore. All stuff nowadays tends to use polkit for authentication.
Offline
I think audio and video groups are respected. Have you tried working without them?
http://wiki.archlinux.org/index.php/Realtime_for_Users
Offline
HAL is deprecated, perhaps that's your issue, that nothing actually uses it anymore. All stuff nowadays tends to use polkit for authentication.
This should not matter. Defaults for polkit should be: 'storage' gives users access to storage, 'power' to power, etc. Otherwise the subject of this thread remains exactly the same: why does /etc/group not matter?
Offline
I think audio and video groups are respected. Have you tried working without them?
http://wiki.archlinux.org/index.php/Realtime_for_Users
Already done those steps. And no, I've never tried to work without being in those groups. Maybe that would make things less functional, but the main point is that the current functionality is not what it should be.
Last edited by jceasless (2010-09-18 21:43:19)
Offline
why does /etc/group not matter?
Because polkit allows finer grained control than what groups provide. By default it's configured to work together with consolekit, if I'm not mistaken. If you want to configure polkit for groups usage, I'm sure it's possible. I wouldn't know for sure though, nothing on my machine uses polkit. I merely have a single app that uses HAL (pcmanfm-0.5.2).
@karol: Yes, audio and video groups are still being used, for alsa and 3d acceleration.
Last edited by Gusar (2010-09-18 21:48:24)
Offline
jceasless wrote:why does /etc/group not matter?
Because polkit allows finer grained control than what groups provide. By default it's configured to work together with consolekit, if I'm not mistaken. If you want to configure polkit for groups usage, I'm sure it's possible. I wouldn't know for sure though, nothing on my machine uses polkit. I merely have a single app that uses HAL (pcmanfm-0.5.2).
.... and this is supposed to be KISS? Throw out the entire model of Unix groups for an undocumented mechanism? Zero entries for polkit or consolekit on the wiki.
And this has been a problem for over a year, before HAL was really considered deprecated.
Offline
Talk to upstream. As far as I know, Arch devs mostly provide pacman-related stuff.
Add the missing articles to the wiki.
Offline
Talk to upstream. As far as I know, Arch devs mostly provide pacman-related stuff.
Add the missing articles to the wiki.
If I knew a thing about it, or could even find more than bug report crumbs and useless freedesktop.org docs regarding either polkit or consolekit, I surely would.
Does this answer really satisfy you? That /etc/group is useless because we have adopted polkit and consolekit? Can you yourself open realtime threads with a normal user in the audio group?
I apologize if I sound frustrated, I'm just hungry for a genuine answer as to why groups are no longer worth anything. They were around long before HAL, after all.
Offline
IIRC mounting and shutdown can be "fixed" by adding rules to visudo. pmount enables mounting for users.
I'm not interested in RT at the moment.
Offline
.... and this is supposed to be KISS?
No, I never said that. Nevertheless it's the direction upstream is going.
And if you were able to configure HAL (it too uses consolekit by default, so if yours uses groups, you must have configured it yourself), you'll be able to figure out how to configure polkit. And then it could be you who writes the wiki article about your discoveries.
Offline
Dunno, if this is what you're looking for, but try disk instead of storage: (edit: No, I don't think it is, nvm.)
$ find /dev/ -group disk
/dev/sg0
/dev/loop0
/dev/sda8
/dev/sda7
/dev/sda6
/dev/sda5
/dev/sda4
/dev/sda3
/dev/sda2
/dev/sda1
/dev/sda
As a side note, do groups affect anything other than just file permissions anyway?
Last edited by Odysseus (2010-09-18 22:59:01)
I'm the type to fling myself headlong through the magical wardrobe, and then incinerate the ornate mahogany portal behind me with a Molotov cocktail.
Offline
@jceasless - Do you use .xinitrc? And if so, are you using consolekit?
exec ck-launch-session windowmanager
Offline
soon consolekit and polkit will be deprecated too. Both are current fashion/crap.
Best to make it manually. No need for idiotic scripts that tend to fail. It is not that difficult to give user/group rights to shutdown, reboot, mount and so on.
No need for sudo by the way. Simply learn how to use ACL and you will never have any problems with permissions.
I explained it here (post #17 and down):
https://bbs.archlinux.org/viewtopic.php?id=89785
HAL is not deprecated: Gnome and KDE still require this.
now, KISS does not mean Ubuntu way. It means that you will use minimum resources to get results. But if this is too complicated then use whatever scripts
Offline
Of *course* user groups are respected - if they weren't, that would be a *huge* security hole.
But, groups are only *part* of the story - there's other stuff to configure too, e.g. /etc/security/limits.d/, /etc/fstab/ ...
"KISS" in the Linux realm means, "keep it simple for the programmer and machine, and ignore how tedious it is for the user."
"KISS" for Arch, means, I imagine, "Don't add a load more hoops for the user to have to jump through."
Learning Linux takes *years*.
Offline
/sbin/shutdown has owner and group root by default, and is not set-user-ID or set-group-ID. Same with /sbin/halt . So that basically answers your question as to why changing user group membership does nothing.
You could try:
chown root:power /sbin/shutdown /sbin/halt
chmod 2755 /sbin/shutdown /sbin/halt
...and see whether that changes anything.
As to the real-time threading, that's reserved for root because real-time threads are a security issue. Any process that can execute with real-time priority may potentially monopolize the CPU. You could use that to denial of service a server, lock up the machine, and so forth. As I remember, there are also options in the kernel configuration related to pre-emptability and the scheduler which are important to actually getting deterministic (or nearly deterministic) real-time behavior.
While the Arch wiki doesn't seem to have any detailed article on real-time scheduling, other distributions do. For example, see the Gentoo guide here. They use PAM and the Linux capabilities security model to set it up.
Overall, I agree with you jceasless -- this stuff is far too complicated for desktop users. Solutions like policy kit are over-engineered, and are really targeted at enterprise or business environments dealing with hundreds to thousands of machines. Though I don't understand why a simple groups solution couldn't be given minor adaptations to work even in that situation.
Offline
No need for sudo by the way. Simply learn how to use ACL and you will never have any problems with permissions.
I explained it here (post #17 and down):
https://bbs.archlinux.org/viewtopic.php?id=89785
Is that really ACL ?
I thought those were separate things from the setuid bit _and_ more importantly you need to mess with the filesystem with your approach, the next update will leave you scratching your head about why it stopped working or why your system got borked (less likely though).
The biggest gripe I have with the alternative *kit stuff is how hard it is to find documentation and _understand_ it when one can find it, luckily there is always someone that figures it out and posts a solution here on the forum, not to mention the trend seems to be to move configuration files to xml, which it seems makes it harder for most people.
The second biggest gripe is how these things seem to change on a whim or by fashion and how they always fail to support the good old groups for people not wishing to have a very fine grained control about who can do what.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
broch wrote:No need for sudo by the way. Simply learn how to use ACL and you will never have any problems with permissions.
I explained it here (post #17 and down):
https://bbs.archlinux.org/viewtopic.php?id=89785Is that really ACL ?
I thought those were separate things from the setuid bit _and_ more importantly you need to mess with the filesystem with your approach, the next update will leave you scratching your head about why it stopped working or why your system got borked (less likely though).The biggest gripe I have with the alternative *kit stuff is how hard it is to find documentation and _understand_ it when one can find it, luckily there is always someone that figures it out and posts a solution here on the forum, not to mention the trend seems to be to move configuration files to xml, which it seems makes it harder for most people.
The second biggest gripe is how these things seem to change on a whim or by fashion and how they always fail to support the good old groups for people not wishing to have a very fine grained control about who can do what.
no, if this would fail, then Arch would need fixing, not permissions.
after +three years this works, while problems with great "permission" daemons are listed on each possible linux forums.
as long as one needs daemons to control access.
ACLs are just more specific forms of permission.
Not to mention that These are common for most OSes (though linux is still behind.. Windows with fine grained
access control). So having experience with one OS it is easy to nderstand the same rules for another.
Thankfully setuid/ACL seem to be resistant to failing daemoms, passing fashions and so on.
Offline
after +three years this works, while problems with great "permission" daemons are listed on each possible linux forums.
Fair enough, I just don't like to change anything in the filesystem unless I really have to. Even changes that seem inconsequential can bring big headaches in the future.
If it works and stands the test of time then it's ok
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1