Hi,
i wrote:
sudo wodim --devices
D. R. Evans wrote:
I get:
[ZB:tmp] sudo wodim --devices
wodim: No such file or directory.
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
Seems to be another problem of wodim with trixie.
I can reproduce it with my post-trixie Sid VM.
There is no desktop active. So i have to set the usual ACL manually:
$ sudo setfacl -m user:thomas:rw /dev/sr0
I also give wodim the setuid bit for this test:
$ sudo chmod 4711 /usr/bin/wodim
$ ls -l /usr/bin/wodim
-rws--x--x 1 root root 467840 Nov 15 2024 /usr/bin/wodim
$
Then
$ wodim --devices
wodim: No such file or directory.
Cannot open SCSI driver!
...
$ sudo wodim --devices
wodim: No such file or directory.
Cannot open SCSI driver!
...
$
Taking away the setuid bit from wodim does not change the outcome:
$ sudo chmod -s /usr/bin/wodim
$ ls -l /usr/bin/wodim
-rwx--x--x 1 root root 467840 Nov 15 2024 /usr/bin/wodim
$
The same errors are reported with
wodim -scanbus
which would report the SCSI address tuples Bus,Lun,Target instead of
device file addresses.
But even without superuser power it can access the individual drive,
where my user has rw-permission by ACL, and inquire info:
$ ls -l /usr/bin/wodim /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Nov 15 08:45 /dev/sr0
-rwx--x--x 1 root root 467840 Nov 15 2024 /usr/bin/wodim
$ wodim dev=/dev/sr0 -toc
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'QEMU '
Identification : 'QEMU DVD-ROM '
Revision : '2.1.'
Device seems to be: Generic CD-ROM.
Using generic SCSI-2 CD-ROM driver (scsi2_cd).
Driver flags :
Supported modes:
first: 1 last 1
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: -1
track:lout lba: 400896 ( 1603584) 89:07:21 adr: 1 control: 6 mode: -1
(The pseudo-drive is actually the Debian 13.1 amd64 netinst ISO.)
The burn programs of which i know what they do, have no problems with
device listing, provided that they have rw-permission on /dev/sr0:
$ cdrskin --devices
cdrskin 1.5.6 : limited cdrecord compatibility wrapper for libburn
...
0 dev='/dev/sr0' rwrw-- : 'QEMU ' 'QEMU DVD-ROM'
...
$ xorriso -devices
xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project.
...
0 -dev '/dev/sr0' rwrw-- : 'QEMU ' 'QEMU DVD-ROM'
...
$
[ZB:tmp] sudo getfacl /dev/sr0
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: cdrom
user::rw-
user:n7dr:rw-
group::rw-
mask::rw-
other::---
Looks normal.
What do you get from
wodim dev=/dev/sr0 -toc
when the setuid bit is not set ?
-----------------------------------------------------------------------
About the weirdness of wodim:
cdrecord and thus its 2006 clone wodim stem from a time when PCs had
difficulties to uphold a data stream of 300 KB/s (2x CD speed) if
the stream producer (e.g. mkisofs) had to collect small files from the
hard disk. Any shortage of data beyond the small buffer of the old
CD drives led to misburns. Joerg Schilling implemented unusual ways to
get outmost priority for the cdrecord process and its i/o.
Since about 25 years the burners are much less picky in this aspect
(by a feature named "burnproof" or "burnfree") and also several MB/s
should be no problem for even the slowest and oldest still running PCs.
I guess that some of these kernel related gestures now got new safety
rails which only the superuser can surpass.
But strace gives me no clue
$ strace wodim --devices >wodim_devices.strace 2>&1
$
The function calls which emit errors are:
access(0x7f102f5f6480, R_OK) = -1 ENOENT (No such file or directory)
...
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
...
prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
...
openat(AT_FDCWD, 0x7fff73a82300, O_RDWR|O_EXCL|O_NONBLOCK) = -1 ENOENT (No such file or directory)
... repeats 26 times ...
uname(0x7fff73a82170) = 0
openat(AT_FDCWD, 0x7fff73a82300, O_RDWR|O_EXCL|O_NONBLOCK) = -1 ENOENT (No such file or directory)
... repeats 255 times ...
After these many ENOENT lines only comes:
uname(0x7fff73a82170) = 0
munmap(0x7f102f211000, 1613824) = 0
write(2, 0x7fff73a82230, 34wodim: No such file or directory. ) = 34
write(2, 0x7fff73a82310, 128
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
For possible transport specifiers try ) = 128
write(2, 0x7fff73a82310, 117'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.
) = 117
exit_group(-1) = ?
+++ exited with 255 +++
Does anybody have an idea how to find out which file paths hide
behind the hex numbers 0x7f102f5f6480 and 0x7fff73a82300 ?
It is strange that openat() uses AT_FDCWD but no "chdir" can be found
among the calls. So this seems to operate in the current working
directory of the shell which started wodim.
What does it want from there ? And why so often ?
The prctl(PR_CAPBSET_READ,...) calls use "cap" values which are not
defined in even very old /usr/include/linux/capability.h .
The highest defined cap in my Sid is decimal 40 = 0x25.
Have a nice day :)
Thomas