gnome-login: system policy prevents pulseaudio from acquiring high-priority scheduling

hi,

gnome-login as user,
since todays update i get this really annoying:
--------
"system policy prevents pulseaudio  from acquiring high-priority scheduling"
password for root
remember authorization
    for this session only
details
  application
  action
  vendor

        cancel  |  authenticate
--------


is this PolicyKit-gnome ?

where can i  DISABLE this ... behaviour?
i could not find    /etc/sysconfig/polkit    or similiar

and NO!  i will not edit "/usr/share/PolicyKit/policy/PulseAudio.policy"


# yum remove PolicyKit\*
[...]
Remove     136 Package(s)


-- 
shrek-m

[Antonio M]

2007/12/8, shrek-m(a)gmx.de <shrek-m(a)gmx.de&gt;:
>  hi,
>
>  gnome-login as user,
>  since todays update i get this really annoying:
>  --------
>  "system policy prevents pulseaudio  from acquiring high-priority scheduling"
>  password for root
>  remember authorization
>      for this session only
>  details
>    application
>    action
>    vendor
>
>          cancel  |  authenticate
>  --------
>
>
>  is this PolicyKit-gnome ?
>
>  where can i  DISABLE this ... behaviour?
>  i could not find    /etc/sysconfig/polkit    or similiar
>
>  and NO!  i will not edit "/usr/share/PolicyKit/policy/PulseAudio.policy"
>
>
>  # yum remove PolicyKit\*
>  [...]
>  Remove     136 Package(s)
>
>
>  --
>  shrek-m
>
>  --
>  fedora-test-list mailing list
>  fedora-test-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-test-list
>  
same here..
Do you mean that you removed PolycyKit???

-- 
Antonio Montagnani
Skype : antoniomontag

Antonio M schrieb:
>  2007/12/8, shrek-m(a)gmx.de <shrek-m(a)gmx.de&gt;:
>    
> > # yum remove PolicyKit\*
> > [...]
> > Remove     136 Package(s
>  same here..
>  Do you mean that you removed PolycyKit??? 
no, i had not removed the 136 packages :(

i was playing with
$ polkit-gnome-authorization

i added  one user  and blocked an  other,
now  none  can edit the "org.pulseaudio  high-priority-scheduling"
because it crashes.

my experiences:
root (local X) can not edit the policies
    a tool for sysadmins but root can not use it  ?
one more tool for a sysadmin to check and to manage  ?
"keep it small keep it simple"  ?
a user can not edit via ssh  X11forwarding  ?
no config-file in /etc/sysconfig/  ?
no possibilty to disable it like selinux  ?


--------
$ vi /etc/PolicyKit/PolicyKit.conf
$ rpm -qf /usr/share/PolicyKit/policy/PulseAudio.policy
pulseaudio-0.9.8-4.fc9
--------

-- 
shrek-m

[Matthias Clasen]

On Sun, 2007-12-09 at 19:45 +0100, shrek-m(a)gmx.de wrote:

>  
>  i was playing with
>  $ polkit-gnome-authorization
>  
>  i added  one user  and blocked an  other,
>  now  none  can edit the "org.pulseaudio  high-priority-scheduling"
>  because it crashes. 
That is simply a bug. I gave David a fix for it; I hope he manages to
push out a fixed build soon. In the meantime, you can use 
polkit-auth --revoke 
to remove the explicit grants that are causing the problem.

>  root (local X) can not edit the policies
>      a tool for sysadmins but root can not use it  ? 
What is the problem with using it as root (apart from the aforementioned
bug) ?

>  one more tool for a sysadmin to check and to manage  ? 
How much checking and managing you want to do depends on your personal
preferences. At least there is a tool, which is more than consolehelper
ever achieved...

>  a user can not edit via ssh  X11forwarding  ? 
Should work, what problem are you seeing ?

>  no possibilty to disable it like selinux  ? 
What do you mean by that ? Blindly allowing every privileged operation
for everybody ? Or denying it for everybody ?

[Kevin Kofler]

Matthias Clasen <mclasen <at> redhat.com> writes:
>  What do you mean by that ? Blindly allowing every privileged
> operation
>  for everybody ? Or denying it for everybody ? 
In cases like this (real-time priority for sound servers), this used to be 
exactly how things worked (or at least were designed to work upstream, 
distributions did not always allow everything SUID that wanted it) in the good 
old days, sound servers were installed SUID root and just always took real-time 
priority. Now PA is SUID root, but asks PolicyKit whether it can actually use 
this privilege. So compared with how things used to work, this is seen as an 
additional restriction, not an additional permission.

Now PolicyKit may also be used to hand out additional permissions, and there it 
would be entirely stupid to default to always granting them, obviously.

        Kevin Kofler

[Matthias Clasen]

On Mon, 2007-12-10 at 07:08 +0000, Kevin Kofler wrote:
>  Matthias Clasen <mclasen <at> redhat.com> writes:
>  > What do you mean by that ? Blindly allowing every privileged operation
>  > for everybody ? Or denying it for everybody ?
>  
>  In cases like this (real-time priority for sound servers), this used to be 
>  exactly how things worked (or at least were designed to work upstream, 
>  distributions did not always allow everything SUID that wanted it) in the good 
>  old days, sound servers were installed SUID root and just always took real-time 
>  priority. Now PA is SUID root, but asks PolicyKit whether it can actually use 
>  this privilege. So compared with how things used to work, this is seen as an 
>  additional restriction, not an additional permission.
>   
For PA, bringing up the dialog and asking for a password is just a grave
UI bug. We should never ask for something like that. Either PA is save
enough to run as root, then the default should be to allow it in active
sessions. If PA doesn't get a straight "yes" back from polkit, it should
not bring up a dialog, but just run without realtime.

>  Now PolicyKit may also be used to hand out additional permissions,
and > there it would be entirely stupid to default to always granting
them, > obviously.

Exactly. That is the point I was trying to make. This needs to be a
case-by-case decision. But it is entirely possible to set up a policy
that always says "yes" or "no", and never brings up stupid dialogs.


Matthias

Matthias Clasen schrieb:
>  On Sun, 2007-12-09 at 19:45 +0100, shrek-m(a)gmx.de wrote:
>
>    
> > i was playing with
> > $ polkit-gnome-authorization
> >
> > i added  one user  and blocked an  other,
> > now  none  can edit the "org.pulseaudio  high-priority-scheduling"
> > because it crashes.
> >     
>
>  That is simply a bug. I gave David a fix for it; I hope he manages to
>  push out a fixed build soon. In the meantime, you can use 
>  polkit-auth --revoke 
>  to remove the explicit grants that are causing the problem.
>     
ok, i will wait and see ...

> > root (local X) can not edit the policies
> >     a tool for sysadmins but root can not use it  ?
> >     
>
>  What is the problem with using it as root (apart from the aforementioned
>  bug) ?
>     
the  gui  does not crash as root but absolutely no authorization was
displayed as root.

the gui (local gnome-terminal `su -`) for root:
all is "greyed out", root can change nothing (block, grant, revoke, modify)

the gui (`ssh -Y user@rawhide` ; `su -`) for root:
all is "greyed out", root can change nothing (block, grant, revoke, modify)


# polkit-auth --user admin --explicit       (granted:pulseaudio)
displayed the authorization
"revoke" was possible


# polkit-auth --user test --explicit    (blocked:pulseaudio)
nothing is displayed but the blocked:authorization must exist because
the warning does not pop up for "test" but for "admin"
i have to use
# polkit-auth --user test --explicit-details
ok, now i see the details
but "revoke" seems to be useless.


all in all:  it seems to me that the gui and tui  need some work.

> > one more tool for a sysadmin to check and to manage  ?
> >     
>
>  How much checking and managing you want to do depends on your personal
>  preferences. At least there is a tool, which is more than consolehelper
>  ever achieved...
>     
i could not find the possibility to add groups.

# rm  /usr/share/PolicyKit/policy/PulseAudio.policy
could be a possibility to remove the annoying pulseaudio warnings for
all users
before i have to give all users the root-password :)


can you import/export/clone policies over the network?
can PolicyKit manage users/groups/worksations in a lan? (central backend
on a server)
  userA@wsA  ==  userA@wsB !=  userA@wsC


> > a user can not edit via ssh  X11forwarding  ?   
>
>  Should work, what problem are you seeing ?
>     
`ssh -Y user@rawhide` ; gnome-terminal :
the gui for unprivileged users "admin" or "test"
the user can  _only_block_himself_  but nothing else, the rest is
"greyed out".


local-X-session, gnome-terminal :
the gui for unprivileged users "admin" or "test"
_all_is_ok_  and both can block, grant, modify
but the given authorizations are not displayed.
in the gnome-terminal i can see warnings eg. "already exist" but not if
it was sucessfully.


not really usefull  :((

> > no possibilty to disable it like selinux  ?
> >     
>
>  What do you mean by that ? Blindly allowing every privileged operation
>  for everybody ? Or denying it for everybody ? 

-- 
shrek-m