Ok I have a look at the kernel code to see how this implements permissions. For these later formats the permissions are encoded on the disk. As the semantics of UDF style permissions are very unix like they are pretty much direct mapped into real system permisions from the on disk format. This implies the disk has 'r' but not 'x' set on the directories in question. Looking at the UDF specification (http://www.osta.org/specs/pdf/udf260.pdf) it does appear that we are implementing the permissions correctly:
The Execute bit for a directory, sometimes referred to as the search bit, has
special meaning. This bit enables a directory to be searched, but not have its
contents listed. For example assume a directory called PRIVATE exists which
only has the Execute permission and does not have the Read permission bit set.
The contents of the directory PRIVATE can not be listed. Assume there is a file
within the PRIVATE directory called README. The user can get access to the
README file since the PRIVATE directory is searchable.
To be able to list the contents of a directory both the Read and Execute
permission bits must be set for the directory. To be able to create, delete and
rename a file or subdirectory both the Write and Execute permission bits must be
set for the directory. To get a better understanding of the Execute bit for a
directory reference any UNIX book that covers file and directory permissions.
The rules defined by the Execute bit for a directory shall be enforced by all
implementations. The exception to this rule applies to Macintosh
implementations. A Macintosh implementation may ignore the status of the Read
bit in determining the accessibility of a directory
At a base level it appears that we are indeed doing what is expected at the kernel level. The disk does not want anyone to look in any of its directories. Clearly this is a non-sensible permissions setup on read-only media where it cannot be rectified.
As has been pointed out in previous comments there are knobs in the mount which allow these permissions to be overridden. It might be appropriate to use dmode to override these permissions on mount, perhaps only for read-only mounts of removable media. I believe that this is best handled in userspace.
Ok I have a look at the kernel code to see how this implements permissions. For these later formats the permissions are encoded on the disk. As the semantics of UDF style permissions are very unix like they are pretty much direct mapped into real system permisions from the on disk format. This implies the disk has 'r' but not 'x' set on the directories in question. Looking at the UDF specification (http:// www.osta. org/specs/ pdf/udf260. pdf) it does appear that we are implementing the permissions correctly:
The Execute bit for a directory, sometimes referred to as the search bit, has
special meaning. This bit enables a directory to be searched, but not have its
contents listed. For example assume a directory called PRIVATE exists which
only has the Execute permission and does not have the Read permission bit set.
The contents of the directory PRIVATE can not be listed. Assume there is a file
within the PRIVATE directory called README. The user can get access to the
README file since the PRIVATE directory is searchable.
To be able to list the contents of a directory both the Read and Execute
permission bits must be set for the directory. To be able to create, delete and
rename a file or subdirectory both the Write and Execute permission bits must be
set for the directory. To get a better understanding of the Execute bit for a
directory reference any UNIX book that covers file and directory permissions.
The rules defined by the Execute bit for a directory shall be enforced by all
implementations. The exception to this rule applies to Macintosh
implementations. A Macintosh implementation may ignore the status of the Read
bit in determining the accessibility of a directory
At a base level it appears that we are indeed doing what is expected at the kernel level. The disk does not want anyone to look in any of its directories. Clearly this is a non-sensible permissions setup on read-only media where it cannot be rectified.
As has been pointed out in previous comments there are knobs in the mount which allow these permissions to be overridden. It might be appropriate to use dmode to override these permissions on mount, perhaps only for read-only mounts of removable media. I believe that this is best handled in userspace.