On Fri, May 24, 2024 at 12:19:39PM +0200, Christian Brauner wrote:
> (2) Opening file handles when the caller has privileges over a subtree
> (2.1) The caller is able to reach the file from the provided mount fd.
> (2.2) The caller has permissions to construct an unobstructed path to the
> file handle.
> (2.3) The caller has permissions to follow a path to the file handle.
These are OR conditions, not AND, right?
> The relaxed permission checks are currently restricted to directory file
> handles which are what both cgroupfs and fanotify need. Handling disconnected
> non-directory file handles would lead to a potentially non-deterministic api.
> If a disconnected non-directory file handle is provided we may fail to decode
> a valid path that we could use for permission checking. That in itself isn't a
> problem as we would just return EACCES in that case. However, confusion may
> arise if a non-disconnected dentry ends up in the cache later and those opening
> the file handle would suddenly succeed.
That feels like a pretty odd adhoc API.
> * An unrelated note (IOW, these are thoughts that apply to
> open_by_handle_at() generically and are unrelated to the changes here):
> Jann pointed out that we should verify whether deleted files could
> potentially be reopened through open_by_handle_at(). I don't think that's
> possible though.
What do you mean with "deleted"? If it is open but unlinked, yes open
by handle allows to get a referene to them. If it is unlinked and
evicted open by handle should not allow to open it, but it's up to the
file systems to enforce this.
> struct dentry *
> exportfs_decode_fh_raw(struct vfsmount *mnt, struct fid *fid, int fh_len,
> - int fileid_type,
> + int fileid_type, bool directory,
This is a reall a only_directories flag, right? Maybe spell that out,
and preferably do that as a flag in a flags paramter so that it also
is obvious in the callers, which a plain true/false is not.
> +struct handle_to_path_ctx {
> + struct path root;
> + enum handle_to_path_flags flags;
> + bool directory;
This and the bool directory passed in a few places
> +};
> +
> - path->dentry = exportfs_decode_fh(path->mnt,
> + path->dentry = exportfs_decode_fh_raw(mnt,
Given that plain exportfs_decode_fh calles are basically dying out
can we just kill it and move the errno gymnastics into the callers
instead of the exportfs_decode_fh vs exportfs_decode_fh_raw
confusion (I still don't understand what's raw about it..)
> if (!capable(CAP_DAC_READ_SEARCH)) {
> + /*
> + * Allow relaxed permissions of file handles if the caller has
> + * the ability to mount the filesystem or create a bind-mount
> + * of the provided @mountdirfd.
> + *
> + * In both cases the caller may be able to get an unobstructed
> + * way to the encoded file handle. If the caller is only able
> + * to create a bind-mount we need to verify that there are no
> + * locked mounts on top of it that could prevent us from
> + * getting to the encoded file.
> + *
> + * In principle, locked mounts can prevent the caller from
> + * mounting the filesystem but that only applies to procfs and
> + * sysfs neither of which support decoding file handles.
> + *
> + * This is currently restricted to O_DIRECTORY to provide a
> + * deterministic API that avoids a confusing api in the face of
> + * disconnected non-dir dentries.
> + */
> +
> retval = -EPERM;
> - goto out_err;
> + if (!(o_flags & O_DIRECTORY))
> + goto out_path;
> +
> + if (ns_capable(ctx.root.mnt->mnt_sb->s_user_ns, CAP_SYS_ADMIN))
> + ctx.flags = HANDLE_CHECK_PERMS;
> + else if (ns_capable(real_mount(ctx.root.mnt)->mnt_ns->user_ns, CAP_SYS_ADMIN) &&
> + !has_locked_children(real_mount(ctx.root.mnt), ctx.root.dentry))
> + ctx.flags = HANDLE_CHECK_PERMS | HANDLE_CHECK_SUBTREE;
> + else
> + goto out_path;
> +
> + /* Are we able to override DAC permissions? */
> + if (!ns_capable(current_user_ns(), CAP_DAC_READ_SEARCH))
> + goto out_path;
> +
> + ctx.directory = true;
Can you split this into a separate helper to keep it readable?
And maybe add a comment oon the real_mount because as-is I don't really
understand it at all.
