Re: trixie: cdrecord can no longer write to CD

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Max Nikulin wrote:
> Not being familiar with strace internals, I suspect that you may need to
> patch the tool to add a special case for openat. Other alternatives are
> debugger

I'm not that optimistic. :)

> or auditd.

I'm not that smart.


I tried to find the reason for the message
  Cannot open SCSI driver!
through

  https://sources.debian.org/src/cdrkit/9:1.1.11-5/wodim/wodim.c?hl=427#L427
  https://sources.debian.org/src/cdrkit/9:1.1.11-5/libusal/scsiopen.c?hl=105#L105
  https://sources.debian.org/src/cdrkit/9:1.1.11-5/libusal/scsitransp.c?hl=167#L167

but ended up at an obscure function pointer setting

  https://sources.debian.org/src/cdrkit/9:1.1.11-5/libusal/usal/usalops.h?hl=68#L68
  #define  SCGO_OPEN(usalp, device)  (*(usalp)->ops->usalo_open)(usalp, device)

for which i find among Linux-related libusal source files only the
Linux PARIDE implementation:

  https://sources.debian.org/src/cdrkit/9:1.1.11-5/libusal/scsi-linux-pg.c?hl=137#L137

which tries to work with "/dev/pg".
That's not IDE/PATA (once /dev/hd, now /dev/sr like USB or SATA) but
IDE via the old parallel printer port.
  https://docs.kernel.org/5.10/admin-guide/blockdev/paride.html

So obviously i got lost in the woods.


> From my point of view, the main question is whether developers/maintainers
> of wodim are active.

Not in wodim. I hope everybody is still well and active otherwise.


> From links posted to the previous thread on this tool, my impression is that
> wodim may fail trying to lock large enough chunk of RAM (that requires
> specific capabilities).

I had hoped to see something like that in the strace output.


> I have seen rant of the cdrecord author on permission model for SCSI
> commands used in Linux kernel. Perhaps very specific usage of ioctl's is
> assumed and some limitations still may be obstacles. Thomas, certainly you
> should be closely familiar with these issues.

In the 20 years that i work with libburn i never bonked against access
restricted SCSI commands.
My notes say that a whitelist once was set in Linux block/scsi_ioctl.c
function blk_set_cmd_filter_defaults(). But that source file seems to
have vanished meanwhile. The function name yields no good results in
search engines, either.

Whatever, in order to encounter such a command restriction, the
program first has to emit ioctl(SG_IO) with an SCSI command. No ioctl
is to see in strace. No SCSI command is reported by
  wodim -V --devices
on my post-trixie Sid. On Debian 12 the run lists a lot of SCSI
transactions and yields the expected device list.


> 04711 mode for the binary looks like excessively drastic measure.

Indeed. But it is what the web proposes as remedy since many years.
Still better than running K3B as superuser.


Have a nice day :)

Thomas