Re: CD writing in future Linux (stirring up a hornets' nest) (was:Rationale for RLIMIT_MEMLOCK?)

From: Jan Engelhardt
Date: Fri Feb 03 2006 - 09:06:57 EST


>> >2. find out the current state of affairs,
>>
>> I am currently able to properly write all sorts of CD-R/RW and DVDÂR/RW,
>> DVD-DL with no problems using
>> cdrecord -dev=/dev/hdb
>> it _currently_ works, no matter how ugly or not this is from either JÃrg's
>> or any other developer's POV - therefore it's fine from the end-user's POV.
>
>How did you manage to burn a dual layer disc? I have been completely
>unsuccessful at doing this at all. :(
>

You have to add -driver=mmc_dvdplusr , because the Dual Layer discs are
not yet in the ProDVD database as it seems.

>> I'm fine (=I agree) with the general possibility of having it setuid,
>> though.
>
>Provided it doesn't allow burning files the real-user shouldn't be able to
>access... But since cdrecord is commonly suid-root, I presume this has long
>been taken into consideration.
>
Security-critical environments like data centers either have a Windows
NT-style machine providing <enter whacky burning software here>, or they
've got a specialized machine that is marked "use for cd burning - note
security implications". Usually there is no problem with that as in that
case, you should remove your ISO you copied over for writing after writing.

>> SUSE currently does it in A Nice Way: setfacl'ing the devices to include
>> read access for currently logged-in users. (Well, if someone logs on tty1
>> after you, you're screwed anyway - he could have just ejected the cd when
>> he's physically at the box.)
>
>Aren't user-groups per-session anyway? Why not simply have the login program
>apply a 'localusers' group to all local sessions and set device permissions
>for that group?

userwhat? You mean supplemental groups as printed by id(1)? I find them
ugly, because it's a real hassle to manage it with files.

In the past, NGROUPS_MAX also was 32, being more of a limit than today.

>To add to the security, perhaps there is a way to remove the
>'localusers' permissions from all backgrounded processes (screen, etc) when
>the user logs out?
>


Jan Engelhardt
--