Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Jan Engelhardt schrieb am 2006-01-24:

> >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.

cdrecord simply assumes that if you don't have access to /dev/hda,
scanning the other devices is pointless, on the assumption it were a
security risk. How this fits into user profiles that might allow access
to /dev/hdc, is unclear to me.

> I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
> is working through the current mechanism, although I can't confirm it.

/dev/hd* and ATA: support DMA, newer cdrecord versions actually check
the DMA speed before starting write operations without burnproof.

> There have been reports that cdrecord does not work when setuid, but only 
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

Locking pages in memory so they aren't swapped out (a requirement for
real-time applications) -- that's the original reason for my
RLIMIT_MEMLOCK question that preceded this thread.

> If you can access a _harddisk_ as a normal user, you _do have_ a security 
> problem. If you can access a cdrom as normal user, well, the opinions 
> differ here. I think you _should not either_, because it might happen that 
> you just left your presentation cd in a cdrom device in a public box. You 
> would certainly not want to have everyone read that out.

That's less of a problem than sending vendor-specific commands - one
might be "update firmware", which would allow the user to destroy the
drive.

> 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.)

There are some things to complicate matters. SUSE patch subfs into the
kernel and ship the needed user-space, think of this as quick
automounter. It releases the drive and unmounts the medium when the last
file is closed. In older SUSE releases, tty? logins didn't trigger
such access controls, only "desktop" logins through kdm or gdm.

> Yes, the device numbering is not optimal. (I already hear someone saying 
> 'have udev make some sweety symlink in /dev'.)
> But in case of /dev/hd*, we are pretty sure of what device is connected 
> where. In case of sd*, it's AFAICS not - the next device plugged in gets 
> the next free sd slot.

What matters is sg, and perhaps sr.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/