Inconsistent interpretation of file mode bits in CD-ROM XA

[skr4n]

In xa.c

const char *
iso9660_get_xa_attr_str (uint16_t xa_attr)
{
  // snip..
  /* Hack alert: wonder if this should be ROTH and XOTH? */
  result[ 9] = (xa_attr & XA_PERM_XSYS) ? 'x' : '-';
  result[10] = (xa_attr & XA_PERM_RSYS) ? 'r' : '-';
  // ..snip
}

posix_mode_t 
iso9660_get_posix_filemode_from_xa(uint16_t i_perms) 
{
  // snip..
#ifdef S_IROTH
  if (i_perms & XA_PERM_ROTH)  mode |= S_IROTH;
#endif
#ifdef S_IXOTH
  if (i_perms & XA_PERM_XOTH)  mode |= S_IXOTH;
#endif
  // ..snip
}

The bitflags used for determining the mode bits for the "other" user is inconsistent between these two functions.
The first function get_xa_attr_str is used by iso-info and cd-info for displaying the mode bits.
The second function get_posix_filemode is not used by any of the CLI programs, however it is part of libcdio's public API.

Here's some documentation I could find on this: cdrom-xa

It seems there are four levels of a user, and I'm not sure which should be used for interpreting these in a POSIX manner not just for the "other" user, but in general.
Or should we not do that, and display these permissions in a different way?

I've tried making a few ISO files with XA using mkisofs, however trying to view them using iso-info seems to lead to misinterpretation.

# Create a test file
touch foo

# create an iso file with xa and r+x mode bits for owner 
mkisofs -file-mode 0500 -xa -o xa.iso foo

# view it with iso-info
iso-info -l xa.iso

# Output shows r+x set for others, instead of owner:
# ----1----xr 0 0 [fn 00] [LSN     25]         0 Jun 05 2026 10:14:10  foo

# do the same, but change the mode bits, set r+x for group
mkisofs -file-mode 0050 -xa -o xa.iso foo

# view it with iso-info
iso-info -l xa.iso

# Output shows r+x set for owner, instead of group:
#   ----1xr---- 0 0 [fn 00] [LSN     25]         0 Jun 05 2026 10:14:10  foo

I'm not sure if mkisofs is at fault here?

[skr4n]

According to this source:

The file attributes must be interpreted as:

  04h 2      File Attributes (big endian):
               0   Owner Read    (usually 1)
               1   Reserved      (0)
               2   Owner Execute (usually 1)
               3   Reserved      (0)
               4   Group Read    (usually 1)
               5   Reserved      (0)
               6   Group Execute (usually 1)
               7   Reserved      (0)
               8   World Read    (usually 1)
               9   Reserved      (0)
               10  World Execute (usually 1)

However, in xa.h:

typedef enum {
    ISO_XA_MARKER_OFFSET =   1024,
    XA_PERM_RSYS =         0x0001,  /**< System Group Read */
    XA_PERM_XSYS =         0x0004,  /**< System Group Execute */

    XA_PERM_RUSR =         0x0010,  /**< User (owner) Read */
    XA_PERM_XUSR =         0x0040,  /**< User (owner) Execute */

    XA_PERM_RGRP =         0x0100,  /**< Group Read */
    XA_PERM_XGRP =         0x0400,  /**< Group Execute */

    XA_PERM_ROTH =         0x1000,  /**< Other (world) Read */
    XA_PERM_XOTH =         0x4000,  /**< Other (world) Execute */
    // ..snip..
} xa_misc_enum_t;

This does not match with the documentation.

• PERM_SYS must be PERM_USR (aka owner)
• PERM_USR must be PERM_GRP
• PERM_GRP must be PERM_OTH
• There is no PERM_SYS as per the doc, only owner, group and world.

This interpretation is also consistent with the output of mkisofs.

[rocky]

Yes, as best as I can tell, this libcdio is wrong here. @pbatard: you have the most experience working with Rock Ridge. Your thoughts?

[pbatard]

@rocky, sorry but I am super busy on other stuff, and I've just been reusing the Rock Ridge feature expecting it to be fit for purpose. Any chance you can get in touch with the person who added the code.

Time permitting I can try to do quick reviews here and there, but please don't ask me to be the project's formal reviewer. I just don't have the scope for that, sorry.

[rocky]

I added the code 18 years ago or so.

I think this is a bug. So, we'll go with the changes then.

[skr4n]

Fixed in #56