On Tue, Jul 25, 2017 at 4:34 PM, Thomas Schmitt <[email protected]> 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 > > >
