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

[Rocky Bernstein]

On Tue, Jul 25, 2017 at 4:34 PM, Thomas Schmitt <address@hidden> wrote:

> 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.
>

Probably an oversight or  ignorance on my part.

>
>
> Have a nice day :)
>
> Thomas
>
>
>