I submitted the separate case LSARC 2009/202 to highlight that similar changes are needed for totem, rhythmbox, and sound-juicer.
The following questions were raised, and I think it makes more sense to resolve these issues in this LSARC 2009/201 case. If the Brasero case changes in any way, I think it makes sense for totem, rhythmbox, and sound-juicer to do things the same way. Issues raised were: - Danek Duvall suggested that we do not deliver a script called /usr/bin/brasero and not move the binary to /usr/bin/brasero.bin. Instead of doing this, he suggests that we instead maintain a patch so that programs re-exec themselves underpfexec if they don't have sys_devices, rather than cluttering up /usr/bin with scripts. This seems reasonable to me. Lin? - Darren Moffat asked; > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices How does this work on Linux kernel based systems ? How do these programs get access to the devices ? Given what these programs do I suspect what what is really wanted is read and sometimes write access to the CD/DVD device nodes. Running them with sys_devices to over come that feels really wrong. Particularly given that "Desktop CD User" is ultimately being added to "Console User". Can't we instead use logindevperm so that the CD/DVD devices are made available with suitable unix permissions - just like we already do for USB removable-media devices, generic usb devices, video devices etc. While there exists precedent for this hack I really don't like it and having it proliferated further isn't a good idea. - Darren Moffat also asked: Why can't this case and the braseo one use the services provided by svc:/network/rpc/smserver ? See rpc.smserverd(1M). PSARC/2000/490 is the reference for the smserver architecture. Lin, I know that you did more research on the security-related changes to brasero. Could you respond? Thanks, Brian
