All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
Date: Thu, 7 Aug 2008 14:10:41 -0700	[thread overview]
Message-ID: <20080807141041.e0d5cccc.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080807114030.4142.76568.stgit@web.messagingengine.com>

On Thu, 07 Aug 2008 19:40:31 +0800
Ian Kent <raven@themaw.net> wrote:
>
> Subject: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls

I fixed that spello

> Patch to add a miscellaneous device to the autofs4 module for routing
> ioctls. This provides the ability to obtain an ioctl file handle for
> an autofs mount point that is possibly covered by another mount.
> 
> The actual problem with autofs is that it can't reconnect to existing
> mounts. Immediately one things of just adding the ability to remount
> autofs file systems would solve it, but alas, that can't work. This is
> because autofs direct mounts and the implementation of "on demand mount
> and expire" of nested mount trees have the file system mounted on top of
> the mount trigger dentry.
> 
> To resolve this a miscellaneous device node for routing ioctl commands
> to these mount points has been implemented in the autofs4 kernel module
> and a library added to autofs. This provides the ability to open a file
> descriptor for these over mounted autofs mount points.
> 
> Please refer to Documentation/filesystems/autofs4-mount-control.txt for
> a discussion of the problem, implementation alternatives considered and
> a description of the interface.
> 
>
> ...
>
> +
> +#define AUTOFS_DEV_IOCTL_SIZE	sizeof(struct autofs_dev_ioctl)
> +
> +typedef int (*ioctl_fn)(struct file *,
> +struct autofs_sb_info *, struct autofs_dev_ioctl *);

Weird layout, which I fixed.

> +static int check_name(const char *name)
> +{
> +	if (!strchr(name, '/'))
> +		return -EINVAL;
> +	return 0;
> +}
> +
> +/*
> + * Check a string doesn't overrun the chunk of
> + * memory we copied from user land.
> + */
> +static int invalid_str(char *str, void *end)
> +{
> +	while ((void *) str <= end)
> +		if (!*str++)
> +			return 0;
> +	return -EINVAL;
> +}

What is this?  gWwe copy strings in from userspace in 10000 different
places without needing checks such as this?

> +/*
> + * Check that the user compiled against correct version of autofs
> + * misc device code.
> + *
> + * As well as checking the version compatibility this always copies
> + * the kernel interface version out.
> + */
> +static int check_dev_ioctl_version(int cmd, struct autofs_dev_ioctl *param)
> +{
> +	int err = 0;
> +
> +	if ((AUTOFS_DEV_IOCTL_VERSION_MAJOR != param->ver_major) ||
> +	    (AUTOFS_DEV_IOCTL_VERSION_MINOR < param->ver_minor)) {
> +		AUTOFS_WARN("ioctl control interface version mismatch: "
> +		     "kernel(%u.%u), user(%u.%u), cmd(%d)",
> +		     AUTOFS_DEV_IOCTL_VERSION_MAJOR,
> +		     AUTOFS_DEV_IOCTL_VERSION_MINOR,
> +		     param->ver_major, param->ver_minor, cmd);
> +		err = -EINVAL;
> +	}
> +
> +	/* Fill in the kernel version. */
> +	param->ver_major = AUTOFS_DEV_IOCTL_VERSION_MAJOR;
> +	param->ver_minor = AUTOFS_DEV_IOCTL_VERSION_MINOR;
> +
> +	return err;
> +}
> +
> +/*
> + * Copy parameter control struct, including a possible path allocated
> + * at the end of the struct.
> + */
> +static struct autofs_dev_ioctl *copy_dev_ioctl(struct autofs_dev_ioctl __user *in)
> +{
> +	struct autofs_dev_ioctl tmp, *ads;

Variables called `tmp' get me upset, but it seems appropriate here.

> +	if (copy_from_user(&tmp, in, sizeof(tmp)))
> +		return ERR_PTR(-EFAULT);
> +
> +	if (tmp.size < sizeof(tmp))
> +		return ERR_PTR(-EINVAL);
> +
> +	ads = kmalloc(tmp.size, GFP_KERNEL);
> +	if (!ads)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (copy_from_user(ads, in, tmp.size)) {
> +		kfree(ads);
> +		return ERR_PTR(-EFAULT);
> +	}
> +
> +	return ads;
> +}
> +
> +static inline void free_dev_ioctl(struct autofs_dev_ioctl *param)
> +{
> +	kfree(param);
> +	return;
> +}
> +
> +/*
> + * Check sanity of parameter control fields and if a path is present
> + * check that it has a "/" and is terminated.
> + */
> +static int validate_dev_ioctl(int cmd, struct autofs_dev_ioctl *param)
> +{
> +	int err = -EINVAL;
> +
> +	if (check_dev_ioctl_version(cmd, param)) {
> +		AUTOFS_WARN("invalid device control module version "
> +		     "supplied for cmd(0x%08x)", cmd);
> +		goto out;

check_dev_ioctl_version() carefully returned a -EFOO value, but this
caller dropped it on the floor.

> +	}
> +
> +	if (param->size > sizeof(*param)) {
> +		err = check_name(param->path);
> +		if (err) {
> +			AUTOFS_WARN("invalid path supplied for cmd(0x%08x)",
> +				    cmd);
> +			goto out;
> +		}
> +
> +		err = invalid_str(param->path,
> +				 (void *) ((size_t) param + param->size));
> +		if (err) {
> +			AUTOFS_WARN("invalid path supplied for cmd(0x%08x)",
> +				    cmd);
> +			goto out;
> +		}
> +	}
> +
> +	err = 0;
> +out:
> +	return err;
> +}
> +
>
> ...
>
> +static void autofs_dev_ioctl_fd_install(unsigned int fd, struct file *file)
> +{
> +	struct files_struct *files = current->files;
> +	struct fdtable *fdt;
> +
> +	spin_lock(&files->file_lock);
> +	fdt = files_fdtable(files);
> +	BUG_ON(fdt->fd[fd] != NULL);
> +	rcu_assign_pointer(fdt->fd[fd], file);
> +	FD_SET(fd, fdt->close_on_exec);
> +	spin_unlock(&files->file_lock);
> +}

urgh, it's bad to have done a copy-n-paste on fd_install() here.  It
means that if we go and change the locking in core kernel (quite
possible) then people won't udpate this code.

Do we have alternative here?  Can we set close_on_exec outside the lock
and just call fd_install()?  Probably not.

Can we export set_close_on_exec() then call that after having called
fd_install()?  I think so.

But not this, please.



  reply	other threads:[~2008-08-07 21:10 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-07 11:40 [PATCH 1/4] autofs4 - cleanup autofs mount type usage Ian Kent
2008-08-07 11:40 ` Ian Kent
2008-08-07 11:40 ` [PATCH 2/4] autofs4 - track uid and gid of last mount requester Ian Kent
2008-08-07 11:40   ` Ian Kent
2008-08-07 20:46   ` Andrew Morton
2008-08-07 22:12     ` Serge E. Hallyn
2008-08-08  3:48       ` Ian Kent
2008-08-08  4:44         ` Ian Kent
2008-08-08 14:58           ` Serge E. Hallyn
2008-08-09  6:05             ` Ian Kent
2008-08-09 13:31               ` Serge E. Hallyn
2008-08-25 18:05                 ` Serge E. Hallyn
2008-08-07 22:15     ` Serge E. Hallyn
2008-08-08  3:13       ` Ian Kent
2008-08-08 15:23         ` Serge E. Hallyn
2008-08-08  3:25     ` Ian Kent
2008-08-08  5:37       ` Ian Kent
2008-08-07 11:40 ` [PATCH 3/4] autofs4 - devicer node ioctl docoumentation Ian Kent
2008-08-07 11:40   ` Ian Kent
2008-08-07 17:38   ` Jim Carter
2008-08-08  3:23     ` Ian Kent
2008-08-09 13:00   ` Christoph Hellwig
2008-08-07 11:40 ` [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Ian Kent
2008-08-07 11:40   ` Ian Kent
2008-08-07 21:10   ` Andrew Morton [this message]
2008-08-08  3:39     ` Ian Kent
2008-08-08  5:31       ` Andrew Morton
2008-08-08  6:12         ` Ian Kent
2008-08-08  6:33           ` Andrew Morton
2008-08-09 12:59   ` Christoph Hellwig
2008-08-09 15:29     ` Ian Kent
2008-08-09 17:18       ` Christoph Hellwig
2008-08-10  5:20         ` Ian Kent
2008-08-09 12:47 ` [PATCH 1/4] autofs4 - cleanup autofs mount type usage Christoph Hellwig
2008-08-09 15:17   ` Ian Kent
  -- strict thread matches above, loose matches on Subject: below --
2008-02-26  3:21 [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Ian Kent
2008-02-26  3:23 ` [PATCH 4/4] autofs4 - add " Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  6:18     ` Ian Kent
2008-02-29 16:24     ` Ian Kent
2008-04-11  7:02       ` Ian Kent
2008-04-12  4:03         ` Andrew Morton
2008-04-14  4:45           ` Ian Kent

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=20080807141041.e0d5cccc.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=autofs@linux.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.