Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension

[Thomas Schmitt]

Hi,

Pete Batard wrote:
> https://bugs.kali.org/view.php?id=4109

I added my insight and suspicion now.
Maybe Raphael bothers to show me the code that controls the xorriso run.


> > i decided against publishing the xorrisofs options without explicit
> > consent by the user.

> I can see your point, though personally, I like openness a lot better.

The source is open. The user data are not necessarily.

> is there encryption that can be involved during ISO generation with
> xorriso?
> [...]
> I don't really like the idea of security through (semi) obscurity.
> [...]
> I still fail to see what kind of private information there is to rat out,

If you want you can install encryption filters between input files and
ISO 9660 files. But that's not the point here.

The potential problem is that users are not generally aware of the recording
of mkisofs options. So they cannot necessarily prepare for a separation
of local private information and information that shall be published by
the ISO.

One thing is sure: My users are more inventive than i am. And evil minded
people can suck info out of things which neither my users nor i can imagine.
I mainly think of local file paths. But there may be other pitfalls.

---------------------------------------------------------------------

I am now exploring how Linux detects Rock Ridge.
I better shouldn't have done. This gives nightmares.

Rock Ridge info is read for directory records if the superblock member
  struct isofs_sb_info.s_rock
is larger than 0.

In fs/isofs/inode.c : isofs_fill_super() it begins its life with value 2,
if not Rock Ridge is disabled by mount options.
Then
        /*
         * Read the root inode, which _may_ result in changing
         * the s_rock flag. Once we have the final s_rock value,
         * we then decide whether to use the Joliet descriptor.
         */
        inode = isofs_iget(s, sbi->s_firstdatazone, 0);
        if (IS_ERR(inode))
                goto out_no_root;

I assume this runs through the only place where .s_rock is set to 1:
fs/isofs/rock.c : parse_rock_ridge_inode_internal() looks for entry "ER".

It is defined in SUSP, but its text content is a matter of Rock Ridge
or other SUSP compliant protocols.
Nevertheless, Linux seems not to be interested in its content.
If the length is halfways plausible, then
  ISOFS_SB(inode->i_sb)->s_rock = 1;

Back in isofs_fill_super(), .s_rock is set to 0 if it has not become 1
meanwhile and if the Joliet Volume Descriptor was found:
        if (sbi->s_rock == 1) {
                joliet_level = 0;
        } else if (joliet_level) {
                sbi->s_rock = 0;

It is unclear to me what happens to an ISO with neither Joliet nor RR.
Will Rock Ridge reading stay active and only be prevented by the fact
that there is no System Use Area at the end of normal ISO 9660 directory
records if there is no Rock Ridge ?


Interesting question:
Why did libcdio not notice that there is no room for a System Use Area
in the 50 KB test ISO from the bug report ?
All directory records are as long as is needed to store their ISO 9660
name. After the possible padding byte there is no more room allocated.


Have a nice day :)

Thomas