On 12/05/2012 03:41 PM, Christoph Wickert wrote:
Am Mittwoch, den 05.12.2012, 11:32 +0100 schrieb Brendan Jones:
I meant creating the group in %post (not editing a file owned by
firstboot).
Sorry, now I am lost.
What group, 'audio' or 'jackuser'? How are these groups created, what
privileges do they have and are privileges assigned to these groups?
AFAIK jackuser is created by the jack-audio-connection-kit package, but
what about audio? What is the reason for this group anyway?
Basically processes run with this group are subject to priority
escalation as described by limits.d file in the
jack-audio-connection-kit package. This is a real concern for audio
users. Another use case for a firstboot patch is the pulse-rt group,
although I'm unsure of the implications.
But the problem of assigning group membership still remains.
Right, but it will continue to remain even with this modification,
because we only "fix" the very first user that gets created, but not
subsequent ones.
Alternatively, we could package something which gets kicked off via
xdg/autostart that could detect this and request sudo priveledges to add
the X user to the group.
That won't help either. Autostart is executed after a user logs in. If
he then is added to a group, he'd need to log in again to allow all
running applications picking up the change.
All really messy and too late now.
Ack.
There is a package realTimeConfigQuickScan which potentially could be
kicked off at start, but having it persist post first log in is really
annoying.
What exactly does this package do? I am really trying to help you but in
order to do so, I need more info. What privileges do we need, what
applications do we need to run or what devices to access?
It basically is a check to see if the logged in user can do all it needs
for "optimal" audio. By itself it does nothing, does not even need root
privileges to do these checks
So yes, we have two problems to solve here the liveuser and the
installed user. liveuser is OK - the installed user is not. How do other
packages handle this? How can a package know to give a particular user
group membership? I can't see a way out of this without user intervention.
I don't think we have a way to add users to a group, at least not on a
packaging level. We don't even seem to be able to do this on the
commandline as /etc/default/useradd can only configure the default group
but not additional default groups.
Short of adding every user to said package, I agree (and think that is
no solution). I think you an Ian may have something with the seat/polkit
idea.
For F19 I will submit the firtboot patch based on the config file and
see if I can make a good case for it.
There is not much use if it is not configurable. I'm afraid that more
people will then come with requests for one or the other group.
Hardcoding groups in firstboot does not fly.
Sorry, perhaps I wasn't clear. Something like groups=... in the
firstboot config file, a programmatic solution rather than our hack.
_______________________________________________
music mailing list
music@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/music
