Hi there 
my question is how can i disable a user playing sounds (such as youtube, audio files etc,) on the system?
thanks
Hello and welcome here.
Because non of your fellow openSUSE users is clairvoyant, can you please tell us which version of openSUSE you use. And as it seems that you want this for GUI users, please tell us which Desktop Environment (KDE, Gnome, …) is used. And if this feature must function for all DEs.
thanks for warm welcome
i’m using the latest opensuse 13.1 with all updates and with pacman repository im a KDE user. and yes it will be good having this functioning for all DEs…
thanks
On 2014-05-03 12:56, smartalgorithm wrote:
>
> Hi there
>
> my question is how can i disable a user playing sounds (such as youtube,
> audio files etc,) on the system?
Traditionally we did that by adding or removing users to the group
“audio”. But this probably does not work now. Just try, and tell us
whatever way it goes
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I checked that in my 13.1, but the users are not members of the group audio. Thus one can not remove them from it.
i did it too… no one is in “audio” group 
Right.
Your user gets the necessary permissions to access the audio device by “logind” when logging in.
This is handled by ACLs.
See:
getfacl /dev/snd/*
getfacl: Entferne fĂĽhrende '/' von absoluten Pfadnamen
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:wolfi:rw-
group::rw-
mask::rw-
other::---
# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
user:wolfi:rw-
group::rw-
mask::rw-
other::---
...
And I don’t think this is configurable.
But maybe you can somehow get logind to not treat your user’s session as active, or prevent the session from being registered with logind?
I have no idea how though…
And it would also prohibit other things like mounting USB disks, installing updates, direct rendering (3d hardware support)…
Well, I know one way to effectively disable logind completely:
remove the line
session optional pam_systemd.so
from /etc/pam.d/common-session.
Then no user should be granted any special rights by logind. You might have to change the polkit permission rules then as well though, and add specific users to certain groups like “audio” or “video”.
And if /etc/pam.d/common-session is not just a symlink but an actual file, not even an update will change it any more.
On 2014-05-03 22:26, hcvv wrote:
>
> I checked that in my 13.1, but the users are not members of the group
> audio. Thus one can not remove them from it.
Ah. I see.
As my setup is upgraded from version to version, my user is included. It
was needed years ago.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-03 23:36, wolfi323 wrote:
>
> smartalgorithm;2641099 Wrote:
>> i did it too… no one is in “audio” group
> Right.
> Your user gets the necessary permissions to access the audio device by
> “logind” when logging in.
Ah.
> This is handled by ACLs.
Dynamic, also.
> And I don’t think this is configurable.
Dunno. :-?
cer@Telcontar:~> apropos logind
logind.conf (5) - Login manager configuration file
systemd-logind (8) - Login manager
systemd-logind.service (8) - Login manager
cer@Telcontar:~>
I would look at those manuals. There is a config file at
“/etc/systemd/logind.conf”, but I don’t see suitable options in the manual.
> Well, I know one way to effectively disable logind completely:
> remove the line
>
> Code:
> --------------------
> session optional pam_systemd.so
> --------------------
> from /etc/pam.d/common-session.
>
> Then no user should be granted any special rights by logind. You might
> have to change the polkit permission rules then as well though, and add
> specific users to certain groups like “audio” or “video”.
Yes, and many things would stop working and you you would have to take
actions, adding people to required groups, perhaps changing the group
owner and permissions of some devices, which is not that trivial because
they are dynamically created.
Not easy…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
AFAIK, it is hardcoded which ACLs get added, but maybe it’s possible to exclude certain users from that automatism.
Not easy…
I didn’t say it was easy… 
But that’s the only way I can think of to achieve what the OP wants (without patching systemd/logind).
Oh, wait.
Maybe you just can set an ACL on login (by running a script), taking away the permissions to access the audio device?
See “man setfacl”.
But that’s just an idea. I don’t know right now how you would get f.e. a script to run (as root) when the user logs in.
One of the reasons I do a fresh installation instead of an upgrade (once every few years or so). It cleans up such artifacts.
On 2014-05-05 10:06, hcvv wrote:
>
> robin_listas;2641243 Wrote:
>> Ah. I see.
>> As my setup is upgraded from version to version, my user is included. It
>> was needed years ago.
> One of the reasons I do a fresh installation instead of an upgrade
> (once every few years or so). It cleans up such artifacts.
Well, but it solves other bigger issues
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-05 08:06, wolfi323 wrote:
>> Not easy…
>>
> I didn’t say it was easy…
>
> But that’s the only way I can think of to achieve what the OP wants
> (without patching systemd/logind).
Me too…
> Oh, wait.
> Maybe you just can set an ACL on login (by running a script), taking
> away the permissions to access the audio device?
> See “man setfacl”.
Ah :-?
> But that’s just an idea. I don’t know right now how you would get f.e. a
> script to run (as root) when the user logs in.
There should be a way for just that, but I don’t know about it.
…bashrc on home directory? But the user could change it. Rather in /etc.
But it would run for every terminal started.
An idea:
+++·························
Try adding this to your /etc/pam.d/login:
session optional pam_exec.so /bin/bash /path/to/your/script.sh
You will need to check in your script if the current user is actually an
administrator (according to whatever your criteria for being
administrator are).
·························+±
or:
> session optional pam_exec.so log=/path/to/logfile /bin/bash /path/to/your/script.sh
I have not tested any of this… ;-?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Or .profile, that should only be run at login.
You could make the file be owned by root and remove write permissions.
But how to start it (or at least the “setfacl”) as root?
If you set it suid root, the login wouldn’t work correctly anymore I suppose.
Maybe with a custom sudo config, that only allows to run that specific command as root without password.