[lkml]   [2006]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

    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&&current->uid!=0 maybe?) scsi layer somewhere?

    I'm fine (=I agree) with the general possibility of having it setuid,

    >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

    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,
    | jengelh's site,
     \ /
      Last update: 2006-01-24 18:45    [W:0.022 / U:8.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site