I'm joining in,
>
>1. compile a list of their requirements,
Have as few code duplicated (e.g. ATAPI and SCSI may share some - after
all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)
Make it, in accordance with the above, possible to have as few kernel
modules loaded as possible and therefore reducing footprint - if I had not
to load sd_mod for usb_storage fun, I would get an itch to load a 78564
byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)
Want to write CDs and DVDs "as usual" (see below).
De-forest the SCSI subsystem for privilege checking (see below).
>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.
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.
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&¤t->uid!=0 maybe?) scsi layer somewhere?
I'm fine (=I agree) with the general possibility of having it setuid,
though.
>3. match the lists found in 1 and 2
>
>4. ONLY AFTER THAT negotiate who is going to change what to make things
> work better for us end users.
>S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
>dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
>list didn't make any progress. My observation is that cdrecord stops
>probing /dev/hd* devices as soon as one yields EPERM, on the assumption
>"if I cannot access /dev/hda, I will not have sufficient privilege to
>write a CD anyways". I find this wrong, Jörg finds it correct and argues
>"if you can access /dev/hdc as unprivileged user, that's a security
>problem".
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.
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.)
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.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
