systemd / systemd/systemd

cdrom_id does not handle certain USB sticks with fake CD rom devices on them

Open
#1,779 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

needs-new-home udev
Dominant language
C
Stars
16.7k
Forks
4.7k
Avg merge
1d 6h
Merged PRs (30d)
140

Description

There are some USB sticks that present themselves as two devices - a regular USB flash drive and a CD drive. This is done so that the data provided from the fake CD drive cannot be modified without using special tools. This is similar to the method used on U3 drives, except that the data on the fake CD is useful.
The fake CD drive on the USB stick I have is handled by cdrom_id in a way that prevents downstream components from automatically mounting the data. There are two problems:
1/ The fake drive does not have a current profile, so cdrom_id assumes that there is no media, even though there is other code to determine whether media is present.
2/ cdrom_id does not look for track information in the last eight bytes of the TOC and thus does not realize that there is a data track on the fake device.
Because of these problems, cdrom_id does not determine that there is data available on the fake drive and thus does not trigger the udev rule that sets up the by-uuid and by-label aliases for disks. These aliases are used in other code (such as in XFCE) for displaying and automounting and thus the drive is not visible on the XFCE desktop and not considered for automounting in XFCE.

The following patch fixes both these problems. I have not submitted it as a patch yet, because I don't have access to information on the TOC layout for CDs and I don't know whether the second part of the patch would introduce any new problems. I have been running the patched cdrom_id on my laptop without any problems.

Can anyone tell me whether the second part of the patch would break anything?

--- ./src/udev/cdrom_id/cdrom_id.c  2015-02-02 17:00:07.251045223 -0800
+++ /home/pfps/cdrom_id.c   2015-10-27 14:30:22.977943769 -0700
@@ -555,7 +555,8 @@
                 feature_profile_media (udev, cur_profile);
                 ret = 0; /* we have media */
         } else {
-                log_debug("no current profile, assuming no media");
+                log_debug("no current profile, media as per detected already");
+                ret = ( cd_media == 0 ) ;
         }

         len = features[0] << 24 | features[1] << 16 | features[2] << 8 | features[3];
@@ -809,7 +810,7 @@
         /* Take care to not iterate beyond the last valid track as specified in
          * the TOC, but also avoid going beyond the TOC length, just in case
          * the last track number is invalidly large */
-        for (p = toc+4, i = 4; i < len-8 && num_tracks > 0; i += 8, p += 8, --num_tracks) {
+        for (p = toc+4, i = 4; i <= len-8 && num_tracks > 0; i += 8, p += 8, --num_tracks) {
                 unsigned int block;
                 unsigned int is_data_track;

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/udev/cdrom_id/cdrom_id.c, focusing on the current-profile media decision and the TOC track loop around the lines shown in the patch. Check the relevant CD TOC layout and existing media-detection behavior, then validate that fake CD devices expose data and receive the expected by-uuid and by-label aliases without affecting ordinary discs.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.