Re: [RFC] Allow block device providers to veto file systems

[Max Vozeler <xam@debian.org>]

Hi Frans,

On Fri, Nov 30, 2007 at 05:01:35PM +0100, Frans Pop wrote:
> On Friday 30 November 2007, Max Vozeler wrote:
> > I've spent some time thinking about possible solutions
> > for #414638 which all essentially worked around the fact
> > that partman offers file systems (via valid_filesystems)
> > that are not actually valid for certain crypto setups.
> 
> Could you elaborate a bit? The report talks about "the 'tmp' setting 
> in /etc/crypttab". Is that equivalent to using random keys?

The problem exists with any kind of file system on
crypto with random keys (please see below). The "tmp" 
option is added only if the underlying crypto device 
uses random keys, but is is just one symptom.

> Why is use of random keys so restricted?

It is limited by the capabilities of the cryptdisks 
script in cryptsetup and the phash=random handling in
loop-AES. Both just create an ext2 unconditionally. 
Hence, if you want to have file system on an encrypted
device with random keys that is re-created each time 
automatically, your choice is limited to ext2.

> Also, isn't swap also allowed with random keys?

Yes, fortunately there is no choice of swap "type" to
be made there. Both loop-AES and cryptdisks know that 
they need to run mkswap on the device and that this is 
enough to make the device usable as swap space.

> > I've pondered different ways of implementing this, and
> > ended up with the attached patch. There are two things
> > I don't like about it: Since we are piping the list of
> > filesystems through the veto scripts, any error in them
> > can cause the list to end up empty. The scripts have to
> > be extra careful not to consume stdin by accident.
> 
> Why pipe them and not just pass them as a parameter?
> Call the script as '$i $dev $id "$filesystems"' and in the script have
> 'filesystems="$3"'.

That's what I tried first.

I changed to piping because otherwise we'd have to do
comparably complex list comparisons. E.g. either:

  foreach filesystem
    foreach veto script
      is vetoed
        skip
      else
        offer in dialog

Which needs to run the veto script(s) many times 
and is slower, or

  foreach veto script
    run with filesystems as parameter
    get vetoed file systems, add to list
  
  foreach filesystem
    if filesystem in veto list
      skip
    else
      offer in dialog

where the "if thing in list" is a little cumbersome 
to do in shell. But I think it can be done if there 
is consensus that it is more robust.

> > The second thing I don't like but couldn't come up with
> > anything better is the name 'valid_filesystems_veto'. If
> > the basic idea is sound, and anyone has suggestions for
> > a better name of the directory, I'm all ears :-)
> 
> {test,check}_valid_filesystems ?

I like check_valid_filesystems, but it could be confused
with "check filesystem" as in fsck. Perhaps test_ is 
better since it is unambiguous.

> > +			for fs in $(cat); do
> > +				case fs in
> > +				ext2)
> > +					echo $fs
> > +					;;
> > +				esac
> > +			done
> 
> The preferred indentation for case statements is:
> 				case fs in
> 				    ext2)
> 					echo $fs
> 					;;
> 				esac
> 
> In this case I'd just use:
> 				case fs in
> 				    ext2) echo $fs ;;
> 				esac

OK, that's fine.

I personally prefer the style I originally used because
it saves one level of (to me) not meaningful indentation,
but that's a matter of taste. I'm happy to change it :-)

Thanks for you feedback.

	Max