| Message ID | 20210216233611.33400-2-vgoyal@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | virtiofsd: Add options to enable/disable posix acl | expand |
On Wed, Feb 17, 2021 at 12:36 AM Vivek Goyal <vgoyal@redhat.com> wrote: > > fuse has an option FUSE_POSIX_ACL which needs to be opted in by fuse > server to enable posix acls. > > Add virtiofsd option "-o posix_acl/no_posix_acl" to let users enable/disable > posix acl support. By default it is disabled as of now. If I read the code correctly, then no_posix_acl will still result in system.posix_acl_* xattr ops being passed through to virtiofsd, which will forward them to the underlying fs, resulting in posix acls appearing to work, but doing so incorrectly (i.e. no change from previous behavior). Possibly better would be to have three different modes of operation: 1) no option: default fall back to broken acl support for backward compat (this could be removed in the future) 2) no_posix_acl: really disable acl support 3) posix_acl: enable proper acl support Thanks, Miklos
On Wed, Feb 17, 2021 at 09:53:04AM +0100, Miklos Szeredi wrote: > On Wed, Feb 17, 2021 at 12:36 AM Vivek Goyal <vgoyal@redhat.com> wrote: > > > > fuse has an option FUSE_POSIX_ACL which needs to be opted in by fuse > > server to enable posix acls. > > > > Add virtiofsd option "-o posix_acl/no_posix_acl" to let users enable/disable > > posix acl support. By default it is disabled as of now. > > If I read the code correctly, then no_posix_acl will still result in > system.posix_acl_* xattr ops being passed through to virtiofsd, which > will forward them to the underlying fs, resulting in posix acls > appearing to work, but doing so incorrectly (i.e. no change from > previous behavior). Yes, and this is confuing me a lot. fuse server has not indicated support for POSIX_ACL, still user can get and set ACLs. fuse_xattr_get() and fuse_xattr_set() must be kicking in. I do see that we have fuse_no_acl_xattr_handlers and that should be able to block setting/getting acls if acl support is not there but we register it only if we are not mounted in init_user_ns. if (sb->s_user_ns != &init_user_ns) sb->s_xattr = fuse_no_acl_xattr_handlers; So question is, should fuse client be fixed as well to block setting and getting acls if fuse server does not support ACL? Or we now need to keep it around for backward compatibility. > Possibly better would be to have three different > modes of operation: > > 1) no option: default fall back to broken acl support for backward > compat (this could be removed in the future) What about FUSE_DONT_MASK in this mode. ACLs are not enabled but user can get/set these. Should that mean we still honor default acl and not apply umask? Probably I should opt for FUSE_DONT_MASK only if posix_acl support is enabled. Given this does not work even today (atleast for virtiofs), so it is not a backward compatibility issue. And its confusing anyway. > 2) no_posix_acl: really disable acl support That is block getting and setting system.posix_acl xattr. Will do that. I think we will have to block it even if somebody has remapped xattrs in virtiofsd. > 3) posix_acl: enable proper acl support Thanks Vivek > > Thanks, > Miklos >
On Wed, Feb 17, 2021 at 4:07 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > On Wed, Feb 17, 2021 at 09:53:04AM +0100, Miklos Szeredi wrote: > > On Wed, Feb 17, 2021 at 12:36 AM Vivek Goyal <vgoyal@redhat.com> wrote: > > > > > > fuse has an option FUSE_POSIX_ACL which needs to be opted in by fuse > > > server to enable posix acls. > > > > > > Add virtiofsd option "-o posix_acl/no_posix_acl" to let users enable/disable > > > posix acl support. By default it is disabled as of now. > > > > If I read the code correctly, then no_posix_acl will still result in > > system.posix_acl_* xattr ops being passed through to virtiofsd, which > > will forward them to the underlying fs, resulting in posix acls > > appearing to work, but doing so incorrectly (i.e. no change from > > previous behavior). > > Yes, and this is confuing me a lot. fuse server has not indicated > support for POSIX_ACL, still user can get and set ACLs. fuse_xattr_get() > and fuse_xattr_set() must be kicking in. > > I do see that we have fuse_no_acl_xattr_handlers and that should > be able to block setting/getting acls if acl support is not there > but we register it only if we are not mounted in init_user_ns. > > if (sb->s_user_ns != &init_user_ns) > sb->s_xattr = fuse_no_acl_xattr_handlers; > > So question is, should fuse client be fixed as well to block setting > and getting acls if fuse server does not support ACL? Or we now need > to keep it around for backward compatibility. Yes, this is a compatibility thing. User namespaces don't work without actual ACL ops, so this was disabled in that case and no backward compatibility worries in that case. We should have disabled this for virtiofs from the start, but at this point we are again stuck with a backward compatibility issue. Alternatively make posix_acl the default, hence fixing the bad behavior is unlikely to cause a regression. > > > Possibly better would be to have three different > > modes of operation: > > > > 1) no option: default fall back to broken acl support for backward > > compat (this could be removed in the future) > > What about FUSE_DONT_MASK in this mode. ACLs are not enabled but > user can get/set these. Should that mean we still honor default > acl and not apply umask? > > Probably I should opt for FUSE_DONT_MASK only if posix_acl support is > enabled. Given this does not work even today (atleast for virtiofs), so > it is not a backward compatibility issue. And its confusing anyway. > > > 2) no_posix_acl: really disable acl support > > That is block getting and setting system.posix_acl xattr. Will do that. > I think we will have to block it even if somebody has remapped xattrs > in virtiofsd. Okay. Thanks, Miklos
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c index 147b59338a..34b2848e61 100644 --- a/tools/virtiofsd/passthrough_ll.c +++ b/tools/virtiofsd/passthrough_ll.c @@ -168,6 +168,7 @@ struct lo_data { /* An O_PATH file descriptor to /proc/self/fd/ */ int proc_self_fd; + int user_posix_acl; }; static const struct fuse_opt lo_opts[] = { @@ -198,6 +199,8 @@ static const struct fuse_opt lo_opts[] = { { "allow_direct_io", offsetof(struct lo_data, allow_direct_io), 1 }, { "no_allow_direct_io", offsetof(struct lo_data, allow_direct_io), 0 }, { "announce_submounts", offsetof(struct lo_data, announce_submounts), 1 }, + { "posix_acl", offsetof(struct lo_data, user_posix_acl), 1 }, + { "no_posix_acl", offsetof(struct lo_data, user_posix_acl), 0 }, FUSE_OPT_END }; static bool use_syslog = false; @@ -630,6 +633,23 @@ static void lo_init(void *userdata, struct fuse_conn_info *conn) "does not support it\n"); lo->announce_submounts = false; } + + if (lo->user_posix_acl == 1) { + /* + * User explicitly asked for this option. Enable it unconditionally. + * If connection does not have this capability, it should fail + * in fuse_lowlevel.c + */ + fuse_log(FUSE_LOG_DEBUG, "lo_init: enabling posix acl\n"); + conn->want |= FUSE_CAP_POSIX_ACL; + } else { + /* + * Either user specified to disable posix_acl, or did not specify + * anything. In both the cases do not enable posix acl. + */ + fuse_log(FUSE_LOG_DEBUG, "lo_init: disabling posix_acl\n"); + conn->want &= ~FUSE_CAP_POSIX_ACL; + } } static void lo_getattr(fuse_req_t req, fuse_ino_t ino, @@ -3533,6 +3553,7 @@ int main(int argc, char *argv[]) .posix_lock = 0, .allow_direct_io = 0, .proc_self_fd = -1, + .user_posix_acl = -1, }; struct lo_map_elem *root_elem; struct lo_map_elem *reserve_elem;
fuse has an option FUSE_POSIX_ACL which needs to be opted in by fuse server to enable posix acls. Add virtiofsd option "-o posix_acl/no_posix_acl" to let users enable/disable posix acl support. By default it is disabled as of now. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> --- tools/virtiofsd/passthrough_ll.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)