From: Al Viro <viro@ZenIV.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
Date: Sat, 2 Jun 2018 18:49:58 +0100 [thread overview]
Message-ID: <20180602174957.GX30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <21804.1527954321@warthog.procyon.org.uk>
On Sat, Jun 02, 2018 at 04:45:21PM +0100, David Howells wrote:
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> > TBH, I would probably prefer separate mount_setattr(2) for that kind
> > of work, with something like
> > int mount_setattr(int dirfd, const char *path, int flags, int attr)
> > *not* opening any files.
> > flags:
> > AT_EMPTY_PATH, AT_NO_AUTOMOUNT, AT_RECURSIVE
>
> I would call these MOUNT_SETATTR_* rather than AT_*.
Why? AT_EMPTY_PATH/AT_NO_AUTOMOUNT are common with other ...at()
syscalls; AT_RECURSIVE - maybe, but it's still more like AT_...
namespace fodder, IMO.
> > attr:
> > MOUNT_SETATTR_DEV (1<<0)
> > MOUNT_SETATTR_NODEV (1<<0)|(1<<1)
> > MOUNT_SETATTR_EXEC (1<<2)
> > MOUNT_SETATTR_NOEXEC (1<<2)|(1<<3)
> > MOUNT_SETATTR_SUID (1<<4)
> > MOUNT_SETATTR_NOSUID (1<<4)|(1<<5)
> > MOUNT_SETATTR_RW (1<<6)
> > MOUNT_SETATTR_RO (1<<6)|(1<<7)
> > MOUNT_SETATTR_RELATIME (1<<8)
> > MOUNT_SETATTR_NOATIME (1<<8)|(1<<9)
> > MOUNT_SETATTR_NODIRATIME (1<<8)|(2<<9)
> > MOUNT_SETATTR_STRICTATIME (1<<8)|(3<<9)
> > MOUNT_SETATTR_PRIVATE (1<<11)
> > MOUNT_SETATTR_SHARED (1<<11)|(1<<12)
> > MOUNT_SETATTR_SLAVE (1<<11)|(2<<12)
> > MOUNT_SETATTR_UNBINDABLE (1<<11)|(3<<12)
>
> So, I like this generally, some notes though:
>
> I wonder if this should be two separate parameters, a mask and the settings?
> I'm not sure that's worth it since some of the mask bits would cover multiple
> settings.
Nah, better put those bits in the same word, as in above. Here bits 0, 2, 4, 6,
8 and 11 tell which attributes are to be modified, with values to set living
in bits 1, 3, 5, 7, 9--10 and 12--13. Look at the constants above..
> Also, should NODIRATIME be separate from the other *ATIME flags? I do also
> like treating some of these settings as enumerations rather than a set of
> bits.
Huh? That's precisely what I'm doing there: bit 8 is "want to change atime
settings", bits 9 and 10 hold a 4-element enumeration (rel/no/nodir/strict).
Similar for propagation settings (bit 11 indicates that we want to set those,
bits 12 and 13 - 4-element enum)...
> I would make the prototype:
>
> int mount_setattr(int dirfd, const char *path,
> unsigned int flags, unsigned int attr,
> void *reserved5);
>
> Further, do we want to say you can either change the propagation type *or*
> reconfigure the mountpoint restrictions, but not both at the same time?
Why? MOUNT_SETATTR_PRIVATE | MOUNT_NOATIME | MOUNT_SUID, i.e. 00101100010000,
i.e. 0xb10 for "turn nosuid off, switch atime polcy to noatime, change propagation
to private, leave everything else as-is"...
And for fsck sake, what's that "void *reserved5" for?
> > With either openat() used as in this series, or explicit
> > int open_tree(int dirfd, const char *path, int flags)
>
> Maybe open_mount(), grab_mount() or pick_mount()?
>
> I wonder if fsopen()/fspick() should be create_fs()/open_fs()...
>
> > returning a descriptor, with flags being
> > AT_EMPTY_PATH, AT_NO_AUTOMOUNT, AT_RECURSIVE, AT_CLONE
> > with AT_RECURSIVE without AT_CLONE being an error.
>
> You also need an O_CLOEXEC equivalent.
Point.
> I would make it:
>
> OPEN_TREE_CLOEXEC 0x00000001
Why not O_CLOEXEC, as with epoll_create()/timerfd_create()/etc.?
> OPEN_TREE_EMPTY_PATH 0x00000002
> OPEN_TREE_FOLLOW_SYMLINK 0x00000004
> OPEN_TREE_NO_AUTOMOUNT 0x00000008
Why? How are those different from normal AT_EMPTY_PATH/AT_NO_AUTOMOUNT?
> OPEN_TREE_CLONE 0x00000010
> OPEN_TREE_RECURSIVE 0x00000020
>
> adding the follow-symlinks so that you don't grab a symlink target by
> accident. (Can you actually mount on top of a symlink?)
You can't - mount(2) uses LOOKUP_FOLLOW for mountpoint (well, user_path(),
actually).
> > Hell, might even add AT_UMOUNT for "open root and detach, to be dissolved on
> > close", incompatible with AT_CLONE.
>
> Cute. Guess you could do:
>
> fd = open_mount(..., OPEN_TREE_DETACH);
> mount_setattr(fd, "",
> MOUNT_SETATTR_EMPTY_PATH,
> MOUNT_SETATTR_NOSUID, NULL);
> move_mount(fd, "", ...);
next prev parent reply other threads:[~2018-06-02 17:50 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 0:05 [PATCH 00/32] VFS: Introduce filesystem context [ver #8] David Howells
2018-05-25 0:05 ` [PATCH 01/32] VFS: Suppress MS_* flag defs within the kernel unless explicitly enabled " David Howells
2018-05-25 0:05 ` [PATCH 02/32] vfs: Provide documentation for new mount API " David Howells
2018-05-25 0:05 ` [PATCH 03/32] VFS: Introduce the basic header for the new mount API's filesystem context " David Howells
2018-05-31 23:11 ` Al Viro
2018-05-31 23:13 ` Al Viro
2018-05-25 0:05 ` [PATCH 04/32] VFS: Add LSM hooks for the new mount API " David Howells
2018-05-25 0:05 ` [PATCH 05/32] selinux: Implement the new mount API LSM hooks " David Howells
2018-05-25 0:06 ` [PATCH 06/32] smack: Implement filesystem context security " David Howells
2018-05-25 0:06 ` [PATCH 07/32] apparmor: Implement security hooks for the new mount API " David Howells
2018-05-25 0:06 ` [PATCH 08/32] tomoyo: " David Howells
2018-05-25 0:06 ` [PATCH 09/32] VFS: Require specification of size of mount data for internal mounts " David Howells
2018-05-25 0:06 ` [PATCH 10/32] VFS: Implement a filesystem superblock creation/configuration context " David Howells
2018-06-07 19:50 ` Miklos Szeredi
2018-07-03 18:33 ` Eric Biggers
2018-07-03 21:53 ` David Howells
2018-07-03 21:58 ` Al Viro
2018-07-03 22:06 ` David Howells
2018-05-25 0:06 ` [PATCH 11/32] VFS: Remove unused code after filesystem context changes " David Howells
2018-05-25 0:06 ` [PATCH 12/32] procfs: Move proc_fill_super() to fs/proc/root.c " David Howells
2018-05-25 0:06 ` [PATCH 13/32] proc: Add fs_context support to procfs " David Howells
2018-05-25 0:06 ` [PATCH 14/32] ipc: Convert mqueue fs to fs_context " David Howells
2018-05-25 0:07 ` [PATCH 15/32] cpuset: Use " David Howells
2018-05-25 0:07 ` [PATCH 16/32] kernfs, sysfs, cgroup, intel_rdt: Support " David Howells
2018-06-21 18:47 ` [16/32] " Andrei Vagin
2018-06-22 12:52 ` David Howells
2018-06-22 15:30 ` Andrei Vagin
2018-06-22 16:57 ` Andrei Vagin
2018-06-23 23:34 ` David Howells
2018-05-25 0:07 ` [PATCH 17/32] hugetlbfs: Convert to " David Howells
2018-05-25 0:07 ` [PATCH 18/32] VFS: Remove kern_mount_data() " David Howells
2018-05-25 0:07 ` [PATCH 19/32] VFS: Implement fsopen() to prepare for a mount " David Howells
2018-05-31 21:25 ` Al Viro
2018-05-25 0:07 ` [PATCH 20/32] vfs: Make close() unmount the attached mount if so flagged " David Howells
2018-05-31 19:19 ` Al Viro
2018-05-31 19:26 ` Al Viro
2018-06-01 1:52 ` Al Viro
2018-06-01 3:18 ` Al Viro
2018-06-01 5:16 ` Al Viro
2018-05-25 0:07 ` [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount " David Howells
2018-06-04 15:05 ` Arnd Bergmann
2018-06-04 15:24 ` David Howells
2018-05-25 0:07 ` [PATCH 22/32] vfs: Provide an fspick() system call " David Howells
2018-05-25 0:07 ` [PATCH 23/32] VFS: Implement logging through fs_context " David Howells
2018-05-25 1:48 ` Joe Perches
2018-05-25 0:07 ` [PATCH 24/32] vfs: Add some logging to the core users of the fs_context log " David Howells
2018-05-25 0:08 ` [PATCH 25/32] afs: Add fs_context support " David Howells
2018-05-25 0:08 ` [PATCH 26/32] afs: Use fs_context to pass parameters over automount " David Howells
2018-06-07 1:58 ` Goldwyn Rodrigues
2018-06-07 20:45 ` David Howells
2018-05-25 0:08 ` [PATCH 27/32] vfs: Use a 'struct fd_cookie *' type for light fd handling " David Howells
2018-05-25 0:08 ` [PATCH 28/32] vfs: Store the fd_cookie in nameidata, not the dfd int " David Howells
2018-05-25 0:08 ` [PATCH 29/32] vfs: Don't mix FMODE_* flags with O_* flags " David Howells
2018-05-25 0:08 ` [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) " David Howells
2018-06-01 6:26 ` Christoph Hellwig
2018-06-01 6:39 ` Al Viro
2018-06-01 8:27 ` David Howells
2018-06-02 3:09 ` Al Viro
2018-06-02 3:42 ` Al Viro
2018-06-02 4:04 ` Al Viro
2018-06-02 15:45 ` David Howells
2018-06-02 17:49 ` Al Viro [this message]
2018-06-03 0:55 ` [PATCH][RFC] open_tree(2) (was Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]) Al Viro
2018-06-04 10:34 ` Miklos Szeredi
2018-06-04 15:52 ` Al Viro
2018-06-04 15:59 ` Al Viro
2018-06-04 19:27 ` Miklos Szeredi
2018-06-04 15:27 ` David Howells
2018-06-04 17:16 ` Matthew Wilcox
2018-06-04 17:35 ` Al Viro
2018-06-04 19:38 ` Miklos Szeredi
2018-06-01 8:02 ` [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8] Amir Goldstein
2018-06-01 8:42 ` David Howells
2018-05-25 0:08 ` [PATCH 31/32] [RFC] fs: Add a move_mount() system call " David Howells
2018-05-31 21:20 ` Al Viro
2018-05-25 0:08 ` [PATCH 32/32] [RFC] fsinfo: Add a system call to allow querying of filesystem information " David Howells
2018-06-04 13:10 ` Arnd Bergmann
2018-06-04 15:01 ` David Howells
2018-06-04 16:00 ` Arnd Bergmann
2018-06-04 19:03 ` David Howells
2018-06-04 20:45 ` Arnd Bergmann
2018-05-31 20:56 ` Test program for move_mount() David Howells
2018-05-31 20:57 ` fsinfo test program David Howells
2018-06-15 4:18 ` [PATCH 00/32] VFS: Introduce filesystem context [ver #8] Eric W. Biederman
2018-06-18 20:30 ` David Howells
2018-06-18 21:33 ` Eric W. Biederman
2018-06-18 23:33 ` Theodore Y. Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180602174957.GX30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).