[Libcdio-devel] [bug #56576] eject_media_linux () not working on some CD-ROM drives

[Thomas Schmitt]

Hi,

this is about
  https://savannah.gnu.org/bugs/index.php?56576

Rocky proposed to continue the discussion on address@hidden.
So i added the following text as comment to the bug report but also
send it to the mailing list, in order to get the discussion moved.

---------------------------------------------------------------------

libcdio tries to issue an SCSI command too and reports:

  INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) 
failed:
       Operation not permitted

(CDROM_SEND_PACKET is the old, deprecated transport ioctl for SCSI
 commands. Currently advised by the Linux kernel community is ioctl(SG_IO).)

It works for me if the user has rw-permission to the drive and i run:

  ./src/cdda-player -ev /dev/sr4

But the symptoms of lack of rw-permission differ from the symptoms
in this bug report. I get:

  open /dev/sr4... ++ WARN: open (/dev/sr4): Permission denied

Do you get any better result if you give cdda-player the drive address
/dev/sr0 explicitely ? Like:

  cdda-player -ev /dev/sr0

---------------------------------------------------------------------

It can hardly be due the way how the drive device file gets opened.
Function eject_media_linux() has:

    /* Make sure the device is opened in read/write mode. */
    ...
    p_env->gen.fd = open (p_env->gen.source_name, O_RDWR|O_NONBLOCK);

That's how growisofs and libburn open their drives, too.
I assume that the growisofs gesture is older than growisofs' transition
from ioctl(CDROM_SEND_PACKET) to ioctl(SG_IO).

So let's look into the SCSI level:
mmc_eject_media() calls mmc_prevent_allow_medium_removal().
(The call to mmc_start_stop_unit(), which would trigger the ejection,
 does obviously not happen after allowing medium removal failed.)

In mmc_prevent_allow_medium_removal() and in mmc_start_stop_unit()
i see transport direction SCSI_MMC_DATA_WRITE.
Both SCSI commands are actually of direction SCSI_MMC_DATA_NONE,
because payload data is neither sent nor received.

It works for me if only the permissions are ok. No superuser power needed.

My kernel is quite old, though. New restrictions might have been added
to the SCSI passthrough facility.

So i propose as experiment to set the proper transport direction in
  lib/driver/mmc/mmc_ll_cmds.c
for the involved low-level functions:
==========================================================================
diff --git a/lib/driver/mmc/mmc_ll_cmds.c b/lib/driver/mmc/mmc_ll_cmds.c
index 66679f4..9e28bfc 100644
--- a/lib/driver/mmc/mmc_ll_cmds.c
+++ b/lib/driver/mmc/mmc_ll_cmds.c
@@ -197,7 +197,7 @@ mmc_prevent_allow_medium_removal(const CdIo_t *p_cdio,
     if (b_prevent)         cdb.field[4] |= 1;
     if (b_persistent)      cdb.field[4] |= 2;

-    return MMC_RUN_CMD(SCSI_MMC_DATA_WRITE, i_timeout_ms);
+    return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, i_timeout_ms);
 }

 /* Maximum blocks to retrieve. Would be nice to customize this based on
@@ -470,7 +470,7 @@ mmc_start_stop_unit(const CdIo_t *p_cdio, bool b_eject, 
bool b_immediate,
       cdb.field[4] = 3; /* close tray for tray-type */
   }

-  return MMC_RUN_CMD(SCSI_MMC_DATA_WRITE, mmc_timeout_ms);
+  return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, mmc_timeout_ms);
 }

 /**
==========================================================================

This change compiles. Afterwards cdda-player -ev still ejects.
But my observation may well be just a red herring.

---------------------------------------------------------------------

> pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sr0
> brw-rw----+ 1 root cdrom 11, 0 Jul  5 22:42 /dev/sr0

I wonder what is hidden behind the "+" permission. What do you get from

  getfacl /dev/sr0

I see

  # file: dev/sr4
  # owner: root
  # group: cdrom
  user::rw-
  user:thomas:rw-
  group::rw-
  mask::rw-
  other::---

Have a nice day :)

Thomas