On Fri, Oct 27, 2017 at 6:03 PM, David Howells [off-list ref] wrote:
Miklos Szeredi [off-list ref] wrote:
quoted
Yes I did mean vfs_parse_sb_flag_option().
Yes, I understand its purpose, but it would be cleaner if all the
option parsing was done in fc->ops->parse_option().
It might be worth introducing the vfs_parse_sb_flag_option(), to be
called from ->parse_option().
I was trying to relieve the filesystem of the requirement to have to deal with
common stuff and also the need to talk directly to the LSM.
No need to talk directly to the LSM:
security_fs_context_parse_option() will do that in VFS code.
How common is common stuff?
dirsync/sync/rw: not handled by all filesystems, those that don't
handle it should reject the option on the new interface
lazytime: handled by generic code, AFAICS, but makes no sense on
read-only fs so those should probably reject it
mand: handled by generic code, but does not make sense for some
filesystems (e.g. those that don't have all the unixy permission
bits).
posixacl: there's no such mount option now. The options is "acl" and
does not get translated to MS_POSIXACL in mount(8). Makes zero sense
to add a previously nonexistent option to the new interface.
silent: makes no sense on the new interface, since we should no longer
be putting error messages into the kernel log.
So that leaves async/ro/nolazytime/nomand options to be handled by all
filesystems.
Not sure how to best handle these differences, but the current code
definitely seems lacking, and I cannot imagine a better way than to
pass all options to filesystem's ->parse_option() and add helper(s) to
handle the generic options.
quoted
quoted
Btw, how would it affect the LSM?
LSM would have to reject a "reset" if not enough privileges to
*create* a new fs instance, since it essentially requires creating a
new config, which is what is done when creating an fs instance.
That's not what I'm asking. Would the reset change LSM state? Reset security
labels and options?
No. And it wouldn't reset any other option that is immutable (e.g.
server IP address).
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html