Re: [RFC PATCH] vfs: syscalls: Add create_automount() and remove_automount()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> What are the insane pioctl semantics you want?

There's a file type beyond file, dir and symlink that AFS supports:
mountpoint.  It appears as a directory with no lookup op in Linux - though it
does support readlink.  When a client walks over it, it causes an automount of
the volume named by the content of the mountpoint "file" on that point.  NFS
and CIFS have similar things.

AFS allows the user to create them and remove them:

	http://docs.openafs.org/Reference/1/fs_mkmount.html
	http://docs.openafs.org/Reference/1/fs_rmmount.html

provided the server grants permission to do so.

OpenAFS, Coda, etc. do this by means of a pair of pioctl() functions (at
least, I think Coda does - it ships the pioctl parameters off to userspace to
handle, so the handling is not actually in the kernel).

> If you can't even open a file on the filesystem, you damn well
> shouldn't be able to to "pioctl" on it.
> 
> And if you *can* open a file on the filesystem, why can't you just use
> ioctl on it?

Directory, not file.  You can do mkdir (requiring write and execute), for
example, in a directory you cannot open (which would require read).  If you
cannot open it, you cannot do ioctl on it.

open(O_PATH) doesn't help because that doesn't let you do ioctl.

David




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux