[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Audio Apps Mini-Policy, v0.1



On Tue, Oct 28, 2003 at 09:43:07PM +1100, Zenaan Harkness wrote:

> Audio applications or applets (ie. executable files) requiring realtime
> privileges should be installed as follows:
>  - user = root
>  - group = audio
>  - permissions
>    - SUID root
>      - have a debconf question asking to allow/ deny this
>      - [debconf question "importance level"??]
>    - user = read, write, execute
>    - group = read, execute
>    - other = read only

  Why read only for other?  Given that they can't execute what is
 presumably a compiled binary I'd treat them as untrusted and not allow
 them to read it at all.

  So:

  	user : rwx
	group: rx
	other: 

> To be really sexy, such audio packages should ask if there are specific
> users that should be added to the audio group upon installation. ??

  An interesting idea, that would make things nicer.

> Finally, installation of such applications should (should they really?)
> check for the local machine's administrator's perms/ ownership overrides
> (specified by dpkg-statoverride) similar to as follows:

  I thought the point of stat override was that this happened without
 any extra effort on the part of the package being installed?

> Anyone, how does Andreas' comment "We _do_ have an audio-group and users
> who need to have access to /dev/{mixer,snd,dsp,..} should be put in
> there, instead of making the app SGID." apply here - ie. am I confused
> about the use of SUID?

  I think that the SGID would be fine if it were just a matter of 
 reading/writing audio devices.  However in the case of tools that need
 realtime priority you'll need SUID to do this.  If you're SUID already
 then being SGID(audio) is redundent.

Steve
--



Reply to: