Re: [PATCH v3 2/2] hostfs: store permissions in extended attributes

From: Johannes Berg <johannes@sipsolutions.net>
To: "Marko Petrović" <petrovicmarko2006@gmail.com>,
	linux-um@lists.infradead.org
Cc: richard@nod.at, anton.ivanov@cambridgegreys.com
Subject: Re: [PATCH v3 2/2] hostfs: store permissions in extended attributes
Date: Tue, 25 Apr 2023 19:11:25 +0200	[thread overview]
Message-ID: <921ccb8824c350bcc63bf97d3fe53bbbe8907cc5.camel@sipsolutions.net> (raw)
In-Reply-To: <CS5ZE898WMR0.153HXDH3AHACG@laptop-fedora>

On Tue, 2023-04-25 at 18:35 +0200, Marko Petrović wrote:
> > It seems that _maybe_, similar to the 'hostfs' kernel argument, there
> > should be a way to contain the set of options?
> > 
> > What do I mean by that? I mean that today, the inside of the virtual
> > machine (for lack of a better word) can only mount outside folders that
> > are contained in the folder indicated by the 'hostfs' argument.
> > Similarly, perhaps the "outside administrator" should be able to
> > indicate that xattr permissions _must_ be used, or _must not_ be used?
> Nice observation. It shouldn't be hard to do this, I can just change
> the interpreted meaning of mnt_use_xattr and hostfs_fs_info->use_xattr
> to comply with this behavior. Thanks for bringing this to attention.
> > 
> > Which would imply a new kernel argument that can be configured to "force
> > use", "force don't use" and "don't care", with perhaps even for backward
> > compatibility the default being "force don't use"?
> > 
> > Not sure. Anton? Richard? Any opinions?

> Maybe xattrperm and noxattrperm can be kernel command line arguments
> used for "force use" and "force don't use" and when none is specified,
> the behavior could be "don't care" which would thus be the default.

Right. Actually now looking at this again, they should probably be flags
inside the hostfs= argument? Like the "append" flag now.

Not really sure what the default should be, perhaps it makes sense to
not allow it by default so it's the same as now? But I don't know how
strict we need to be about this.

> That may also be reasonable for the purpose of backward compatibility
> since the usage of extended attributes would then be specified as an mount
> option and applications not aware of it would just use the old behavior
> (since the extended attributes would be used only when specified in
> mount options).

Right. I was more thinking of the isolation aspects of this.

> On the other hand, that would require a little different mounting of
> root filesystem. Maybe adding rootxattrperm as a new kernel command line
> argument for mounting root with "rootfstype=hostfs hostfs=rootxattrperm"
> could be the solution (for when root should use extended attributes, but
> the general behavior should still be "don't care")?
> What are your opinions?

Oh, that's a good point too. I don't think I have much of an opinion on
it though. But yeah, why not have another flag "rootxattrperm" for the
hostfs= option, along with xattrperm and noxattrperm (or allowxattrperm
and forcexattrperm if we need noxattrperm to be the default per above.)

johannes

PS: Note that in uml/next my patches with the split are merged, so when
you rebase please rebase on that and adjust accordingly with the
exported symbol we discussed.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um