Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor

On Thu, 28 Feb 2008 16:08:20 +0900 Ian Kent <raven@xxxxxxxxxx> wrote:



What problem are you actually trying to solve here?

The basic problem arises only when we want to restart the user space
daemon and there are active autofs managed mounts in place at exit (ie.
autofs mounts that have busy user mounts). They are left mounted and
processes using them continue to function. But then, when we startup
autofs we need to reconnect to these autofs mounts, some of which can
covered the by mounted file systems, and hence the need for another way
to open an ioctl descriptor to them.

So we want to store persistant state in the kernel across userspace process
invokations. That's normally done with a thing called a "file" ;) Could we
stick all the necessary state into files in a pseudo-fs and have the daemon
go and open and read them all when it restarts?

It may have been overkill to re-implement all the current ioctls (and
add a couple of other much needed ones)

I don't understand that bit. But then, I don't have a clue how autofs
works.

but I though it sensible for
completeness, and we get to identify any possible problems the current
ioctls might have had due to the use of the BKL (by the VFS when calling
the ioctls).

It isn't a good idea to wait for races to reveal themselves. It will take
years, especially with a system which has as low a call frequency as autofs
mounting. And once a bug _does_ reveal itself, by then we'll have tens of
millions of machines out there running that bug.

So, why do we need the uid and gid? When someone walks over an autofs
dentry that is meant to cause a mount we send a request packet to the
daemon via a pipe

connector or genetlink would be more fashionable transports.

which includes the process uid and gid, and as part of
the lookup we set macros for several mount map substitution variables,
derived from the uid and gid of the process requesting the mount and
they can be used within autofs maps.

yeah, could be a problem. Hopefully the namespace people can advise.
Perhaps we need a concept of an exportable-to-userspace namespace-id+uid,
namespace-id+gid, namespace-id+pid, etc for this sort of thing. It has
come up before. Recently, but I forget what the context was.

This is all fine as long as we don't need to re-connect to these mounts
when starting up, since we don't get kernel requests for the mounts, we
need to obtain that information from the active mount itself.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor
    ... daemon and there are active autofs managed mounts in place at exit (ie. ... scan the file systems, mounting every mount. ...
    (Linux-Kernel)
  • Re: [VFS-RFC] autofs4 and bind, rbind and move mount requests
    ... The mounts appear in a map whose source can be a file or NIS or other ... A master map tells autofs where to find the actual ... Not sure that will be without pain down the track from a support ...
    (Linux-Kernel)
  • recent nfs change causes autofs regression
    ... I am re-sending this after help from Ian and git-bisect. ... I cannot find an acceptable workaround that I can implement. ... I believe it's caused by the NFS change that forces multiple mounts from ... Since in my setup they are managed by autofs, and the autofs map is managed ...
    (Linux-Kernel)
  • [PATCH 0/13] autofs4 - various cleanups, updates and bug fixes
    ... This is the first set of patches for autofs in moving toward a ... failed-lookup - fix stale dentrys stopping mounts. ... expire-cleanup - change return values and names of two functions ... needed for a rework of autofs direct mounts. ...
    (Linux-Kernel)
  • Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference
    ... Yes this is data being sent to a userspace daemon (Ian pls ... At the moment autofs only uses the packet->pid for logging purposes. ... not the user space daemon communicating with the kernel ... ... which should be running in the root pid namespace. ...
    (Linux-Kernel)