[Fedora-music-list] Spin Approval

[Brendan Jones]

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.