is there an autofs roadmap somewhere?

is there an autofs roadmap somewhere?

[Lever, Charles]

new to the game.

i'm wondering what features autofs developers have in mind for the near
future.

Re: is there an autofs roadmap somewhere?

[raven]

On Tue, 22 Jun 2004, Lever, Charles wrote:

> new to the game.
> 
> I'm wondering what features autofs developers have in mind for the near
> future.

Charles. Why did you have to ask "that" question!

There are quite a few things that people here on the list have asked for, 
that for one reason or another, are quite difficult to implement. I won't 
go there now.

The big issue for me is that, atm autofs does not have expected 
functionality in two areas. One is the lazy mounting of multi-mount maps 
and second, direct mounts that behave as expected (there's limited 
functionality now).

To be honest I've spent a lot of time fixing bugs. When that settles down 
(soon I hope) I want to re-work the code to sort out the above.

Once autofs has functionality expected of an automounter, a roadmap of 
additional features would be good to develop.

There's a redevelopment by Mike Waychison and Tim Hocking (of Sun) 
underway but they haven't delivered any product yet. Perhaps we'll see 
something in the 2.7 - 2.8 time frame. Their design will take much of the 
function into the kernel using callback helper utilities.

There's also the 800 mount limit in the sunrpc code for NFS v2 and v3 
mounts, but you know about that.

But what functionality do you need?
And what do you think would be useful?

Ian

submount vs automount

[Jim Carter]

SuSE 9.1 includes a thing called submount (subfs.ko, /sbin/submountd) which
looks to me to be very similar to autofs.  It may or may not also be in
Gentoo.  They use it to control removeable media, i.e. CD or floppy.  
Here's the Sourceforge project page:

http://sourceforge.net/projects/submount/

(Hiss, boo: SuSE forgot to include the source in their hacked kernel, so if
you recompile the kernel yourself, the default subfs mounts stop working.  
Get the source from Sourceforge if you're in that situation.)

As far as I can see, the differences between autofs and subfs are:

A.  submountd is spawned by the kernel module when someone accesses a subfs 
directory.  It then mounts the media.  It doesn't start at boot time and 
persist.

B.  The program is designed to unmount very fast -- I'd say it polls once a
second.  This makes it act like Windoze.  (No flame wars, please, about
whether this is good or bad.)  The timeout can be set differently for
different filesystems.  Automount has the same timeout for all filesystems.

C.  There is the option to use a different program to do the mount.  A NFS 
mounter is provided, although the docs say that "autofs is, and will 
continue to be, the preferred solution for complex NFS installations".

D.  There is an option to mount the filesystem (floppy or CD) with the
UID-GID of the originally requesting user.  With automount, the UID or GID
option can be passed to mount, if the UID is known when the system is
configured, or if all relevant users are in the group (and it has write
permission).

It would seem to me that the main differences between submount and
automount are in per-filesystem options which are relatively easy to
implement, but which are essential for the role submount is designed to
fill.  Personally, I would rather have only one automounter to manage and I
don't think submount is the preferred one.

On the issue of the alternative mount script: I've been thinking of a
crypto thingy which is mounted on demand (by automount), but it would have
to pop a dialog box to get the passphrase for the crypto filesystem.  So
here's a case needing an arbitrary script to mount the filesystem.  It
would also need a "never unmount" option, e.g. timeout=0.  The idea is that
when you suspend a laptop, the suspend script explicitly unmounts the
crypto filesystem.  Now the enemy agent steals the laptop.  (It's much
harder to steal the thing when it's on James Bond's lap and he's typing on
it.)  Oooo, lots of hot unencrypted secret keys!  But when he tries to read
them, he's asked for the passphrase, which he doesn't have.

It sounds like I'm proposing a few more mount options that the autmount
daemon is going to have to identify and remove.  To avoid name collisions
we ought to have a distinctive format for automount options.  One idea:  
they all begin with upper case A.  Another idea: A=timeout=0, i.e. a single
"A" is the name of the (only) automount option, but the "value" is
potentially a key=value pair.

Here's a spiffy redesign: when the user hits the eject button on the CD, 
autofs.ko is aware of it (probably the hardest part) and signals the daemon 
to unmount if possible.  If that could be made to work, it would eliminate 
the stupid Windoze-style polling.  But floppies work differently.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: submount vs automount

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Carter wrote:
> SuSE 9.1 includes a thing called submount (subfs.ko, /sbin/submountd)
which
> looks to me to be very similar to autofs.  It may or may not also be in
> Gentoo.  They use it to control removeable media, i.e. CD or floppy.
> Here's the Sourceforge project page:
>
> http://sourceforge.net/projects/submount/
>
> (Hiss, boo: SuSE forgot to include the source in their hacked kernel,
so if
> you recompile the kernel yourself, the default subfs mounts stop
working.
> Get the source from Sourceforge if you're in that situation.)
>

IIRC, SuSE has this module as an external rpm: km_submount.  You'd have
to rebuild that rpm.

> As far as I can see, the differences between autofs and subfs are:
>
> A.  submountd is spawned by the kernel module when someone accesses a
subfs
> directory.  It then mounts the media.  It doesn't start at boot time and
> persist.
>
> B.  The program is designed to unmount very fast -- I'd say it polls
once a
> second.  This makes it act like Windoze.  (No flame wars, please, about
> whether this is good or bad.)  The timeout can be set differently for
> different filesystems.  Automount has the same timeout for all
filesystems.
>
> C.  There is the option to use a different program to do the mount.  A
NFS
> mounter is provided, although the docs say that "autofs is, and will
> continue to be, the preferred solution for complex NFS installations".
>
> D.  There is an option to mount the filesystem (floppy or CD) with the
> UID-GID of the originally requesting user.  With automount, the UID or GID
> option can be passed to mount, if the UID is known when the system is
> configured, or if all relevant users are in the group (and it has write
> permission).

This is just semantically racy.  If someone ssh'es into you laptop and
accesses the mount before you do, you can't access it.  A better
approach IMHO is to mount with the UID of the user on :0, unmounting it
on logout if possible. Thoughts?

>
> It would seem to me that the main differences between submount and
> automount are in per-filesystem options which are relatively easy to
> implement, but which are essential for the role submount is designed to
> fill.  Personally, I would rather have only one automounter to manage
and I
> don't think submount is the preferred one.
>
> On the issue of the alternative mount script: I've been thinking of a
> crypto thingy which is mounted on demand (by automount), but it would have
> to pop a dialog box to get the passphrase for the crypto filesystem.  So
> here's a case needing an arbitrary script to mount the filesystem.

Sure,  I'd like to see this eventually as fstype=other, with the real
fstype handled by the script/program that mounts it.  Make it
configurable by saying fstype=other:/path/to/mounter.

It
> would also need a "never unmount" option, e.g. timeout=0.

We would first have to allow per-mount timeouts..

The idea is that
> when you suspend a laptop, the suspend script explicitly unmounts the
> crypto filesystem.

How is this possible?  When you suspend, you'll still have open files to
the file system.


Now the enemy agent steals the laptop.  (It's much
> harder to steal the thing when it's on James Bond's lap and he's typing on
> it.)  Oooo, lots of hot unencrypted secret keys!  But when he tries to
read
> them, he's asked for the passphrase, which he doesn't have.

A better approach would have the loop backed device (I'm assuming you
are using this for the crypto) flush the keys, and have *it* ask you to
refresh them.  It will however have to remember who to ask :)

Another problem with this is that you can end up easily deadlocking your
machine.  For example, consider the situation where your home directory
is encrypted (being the mount with the most security critical data).

If the 'dialog' uses any communication channel in the homedir (unix
socket?), then it will deadlock the machine.  The alternative is to
force all communication channels into something like /tmp (which itself
is probably the second most important fs you'd want to encrypt).  So
you'd have to be extremely careful and put it in something like
/var/run/crypto/sockets and ensure that it never gets encrypted.

But even in this case, all your desktop processes would probably be
uninterruptble while you are being queried for passcodes.  So you could
deadlock cause your window manager can't display the prompt.

Sounds pessimistic, I know, but this leads to the conclusion that you
should encrypt your entire homedir.. :\

>
> It sounds like I'm proposing a few more mount options that the autmount
> daemon is going to have to identify and remove.  To avoid name collisions
> we ought to have a distinctive format for automount options.  One idea:
> they all begin with upper case A.  Another idea: A=timeout=0, i.e. a
single
> "A" is the name of the (only) automount option, but the "value" is
> potentially a key=value pair.

This is deviating even more from the options understood by other unices'
automounters.  Please don't.

>
> Here's a spiffy redesign: when the user hits the eject button on the CD,
> autofs.ko is aware of it (probably the hardest part) and signals the
daemon
> to unmount if possible.  If that could be made to work, it would
eliminate
> the stupid Windoze-style polling.  But floppies work differently.
>

This won't work and has been discussed at length before on
linux-hotplug-devel.  A lot of removeable medias don't have any way for
the system to know you are ejecting them.  A good example is CF media.
It was determined that polling was the only way to have this work.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA3G+DdQs4kOxk3/MRAv8GAJ4yC2MybmIwCYLy77rJrDZ6lqK9QACcCgpY
A4JFk9XixG2lNeDX6zuyl/k=
=C7uC
-----END PGP SIGNATURE-----

Re: submount vs automount

[Jim Carter]

On Fri, 25 Jun 2004, Mike Waychison wrote:
> > Get the source from Sourceforge if you're in that situation.)
> 
> IIRC, SuSE has this module as an external rpm: km_submount.  You'd have
> to rebuild that rpm.

Aha, missed that one.  The way submount is structured, the source RPM 
probably has both the module and the utility.

> > D.  There is an option to mount the filesystem (floppy or CD) with the
> > UID-GID of the originally requesting user...
> 
> This is just semantically racy.  If someone ssh'es into you laptop and
> accesses the mount before you do, you can't access it.  A better
> approach IMHO is to mount with the UID of the user on :0, unmounting it
> on logout if possible. Thoughts?

It's an interesting denial of service attack.  Agreed that it's better to 
identify and use the user on the physical console.  logindevperm is 
generally set up to re-own a number of special files specially for a 
console login.  But here, the ownership determination has to occur a 
long time after the login.  With X-windows, it may not always be clear what 
the console is and who is logged on to it, particularly in unusual 
configurations, like multi-headed.

> > The idea is that
> > when you suspend a laptop, the suspend script explicitly unmounts the
> > crypto filesystem.
> 
> How is this possible?  When you suspend, you'll still have open files to
> the file system.

I'm thinking of parking the unencrypted secret keys in a small crypto 
filesystem.  Generally the programs (postfix, openvpn, pluto, apache, etc.)
either read the key once at startup (or HUP) and then close it, or read it 
once when each connection starts.  They don't hold it open -- so the 
filesystem can be unmounted and remounted during a suspend.  You're quite 
right that this approach would work poorly if you're editing secret data in 
an encrypted work area, and you expect to unmount it across a suspend, yet 
leave the editor running.  Of course, that would violate any competent 
security procedures...

> A better approach would have the loop backed device (I'm assuming you
> are using this for the crypto) flush the keys, and have *it* ask you to
> refresh them.  It will however have to remember who to ask :)

Flushing the key: good.  Reaching from the bowels of the kernel to pop a 
dialog box: not so good.

> > Here's a spiffy redesign: when the user hits the eject button on the CD,
> > autofs.ko is aware of it (probably the hardest part) and signals the
> daemon
> > to unmount if possible.  If that could be made to work, it would
> eliminate
> > the stupid Windoze-style polling.  But floppies work differently.

> This won't work and has been discussed at length before on
> linux-hotplug-devel.  A lot of removeable medias don't have any way for
> the system to know you are ejecting them.  A good example is CF media.
> It was determined that polling was the only way to have this work.

I suppose you're right, too many device types can't tell you they're 
ejecting until it's too late.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: submount vs automount

[Paul Jakma]

On Fri, 25 Jun 2004, Mike Waychison wrote:

> This is just semantically racy.  If someone ssh'es into you laptop 
> and accesses the mount before you do, you can't access it.  A 
> better approach IMHO is to mount with the UID of the user on :0, 
> unmounting it on logout if possible. Thoughts?

Why should the user on :0 be special?

This is a question of policy. And there are really two questions 
here. The important one:

- Does the user have the credentials to be allowed to mount this 
device?

we already have things like pam_console and logindevperm to assist 
with answering this question, if an admin so desires.

The lesser question of, applying mainly to removable media with 
certain non-POSIX fs's:

- what credentials should the mount apply to files?

The answer to last one, given you have an answer to first question, 
is almost certainly "the credentials which triggered the mount".

no?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
Live fast, die young, and leave a flat patch of fur on the highway!
 		-- The Squirrels' Motto (The "Hell's Angels of Nature")

Re: submount vs automount

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Jakma wrote:
> On Fri, 25 Jun 2004, Mike Waychison wrote:
>
>> This is just semantically racy.  If someone ssh'es into you laptop and
>> accesses the mount before you do, you can't access it.  A better
>> approach IMHO is to mount with the UID of the user on :0, unmounting
>> it on logout if possible. Thoughts?
>
>
> Why should the user on :0 be special?

Cause this is the kind of policy I'd like to see :)

>
> This is a question of policy. And there are really two questions here.
> The important one:
>
> - Does the user have the credentials to be allowed to mount this device?
>
> we already have things like pam_console and logindevperm to assist with
> answering this question, if an admin so desires.
>

Yup. However, this doesn't connect nicely with mount(8).  mount(8) only
mounts as a user according to /etc/fstab rules, not by block device
owner :\   Maybe this should be fixed up somehow.


> The lesser question of, applying mainly to removable media with certain
> non-POSIX fs's:
>
> - what credentials should the mount apply to files?
>
> The answer to last one, given you have an answer to first question, is
> almost certainly "the credentials which triggered the mount".
>
> no?
>

Sure, but 'who is allowed to trigger the mount'?

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4DzBdQs4kOxk3/MRAvROAJ49u+Fa7l2cPubk0SbL/r83Nohi1gCgieZs
SIBJRsZbX5Q+rGWZQFYD8A8=
=ufzo
-----END PGP SIGNATURE-----

Re: submount vs automount

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Waychison wrote:
> Paul Jakma wrote:
>>>This is a question of policy. And there are really two questions here.
>>>The important one:
>>>
>>>- Does the user have the credentials to be allowed to mount this device?
>>>
>>>we already have things like pam_console and logindevperm to assist with
>>>answering this question, if an admin so desires.
>>>
>
>
> Yup. However, this doesn't connect nicely with mount(8).  mount(8) only
> mounts as a user according to /etc/fstab rules, not by block device
> owner :\   Maybe this should be fixed up somehow.
>

Oops.  My bad, should have RTFMed mount(8) -- 'owner'.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4D1xdQs4kOxk3/MRAtpVAJ95U9aHo2wm4vNLI25gf10WErrZYACfeIpB
DneDKsyOskWQiVsDlt3ZFzg=
=E3us
-----END PGP SIGNATURE-----

Re: submount vs automount

[Paul Jakma]

On Mon, 28 Jun 2004, Mike Waychison wrote:

> Oops.  My bad, should have RTFMed mount(8) -- 'owner'.

Ah yes. Well, that saves having to parse that in autofs.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
To communicate is the beginning of understanding.
 		-- AT&T

Re: submount vs automount

[Paul Jakma]

On Mon, 28 Jun 2004, Mike Waychison wrote:

>> Why should the user on :0 be special?
>
> Cause this is the kind of policy I'd like to see :)

It doesnt make sense though. Eg, I remember in College the 
SPARCStation labs (for some reason) each only had one workstation 
with a floppy device. 9/10 the user using the floppy was not on :0.0.

I can imagine something similar today with Zip/Jazz/DVR-RW+packet 
UDF/$CHIC_REMOVABLE_MEDIA_DE_JOUR.

> Yup. However, this doesn't connect nicely with mount(8).  mount(8) 
> only mounts as a user according to /etc/fstab rules, not by block 
> device owner :\ Maybe this should be fixed up somehow.

Hmm, that's a decent point.

> Sure, but 'who is allowed to trigger the mount'?

Whoever is allowed to access the device surely?

> --
> Mike Waychison
> Sun Microsystems, Inc.
> 1 (650) 352-5299 voice
> 1 (416) 202-8336 voice
> http://www.sun.com

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
Victory uber allies!

Re: submount vs automount

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Jakma wrote:
> On Mon, 28 Jun 2004, Mike Waychison wrote:
>
>>> Why should the user on :0 be special?
>>
>>
>> Cause this is the kind of policy I'd like to see :)
>
>
> It doesnt make sense though. Eg, I remember in College the SPARCStation
> labs (for some reason) each only had one workstation with a floppy
> device. 9/10 the user using the floppy was not on :0.0.
>
> I can imagine something similar today with Zip/Jazz/DVR-RW+packet
> UDF/$CHIC_REMOVABLE_MEDIA_DE_JOUR.
>

This policy has to be determined on a machine-by-machine basis.  I think
we can agree to that.

I just chose to examine the :0 policy because doing so allows us to
explore the implications of such an implementation.

For example, after considering the 'owner' bit, I realize now that
autofs would:

- - still have to parse for such an option as it runs as root and would
likely have to setuid to the user in question (so umount(8) still works).

- - which implies that automount would need to know who triggered the
mount, which isn't possible without a protocol jump.

Going back to earlier discussion, when Jim Carter discussed the
'first-acccess / mount-owner' scenario, I think there has to be a
compromise between security and functionality.  Prescribing policies
such as ':0' helps enforce some level of security access to the medium,
while the 'no-policy policy' is just as bad as setups described above
where your fd device file is o+rw.



- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4EaTdQs4kOxk3/MRAmLJAJ9mrD33QJBrH63X6TAeWfAki9PMjACdEnZD
0gLuGLf4npMYOUPC8j+OzIA=
=vveZ
-----END PGP SIGNATURE-----

Re: submount vs automount

[Paul Jakma]

On Mon, 28 Jun 2004, Mike Waychison wrote:

> This policy has to be determined on a machine-by-machine basis.  I 
> think we can agree to that.

Or site by site. (yeah, pam_console, eg, doesnt do directory lookups 
for config, but hey, maybe one day)

> I just chose to examine the :0 policy because doing so allows us to 
> explore the implications of such an implementation.

ok.

> For example, after considering the 'owner' bit, I realize now that
> autofs would:
>
> - still have to parse for such an option as it runs as root and would
> likely have to setuid to the user in question (so umount(8) still works).
>
> - which implies that automount would need to know who triggered the
> mount, which isn't possible without a protocol jump.

Yes, it would. I didnt realise automount did not have access to 
credentials of the process which triggered the 'lookup'.

> Going back to earlier discussion, when Jim Carter discussed the 
> 'first-acccess / mount-owner' scenario, I think there has to be a 
> compromise between security and functionality.  Prescribing 
> policies such as ':0' helps enforce some level of security access 
> to the medium,

:0 is a not good policy. The user on :0 might not be the user whose 
data is on the media autofs is to mount - which is a security breach. 
Further, are you suggesting that automount should know how to find 
out which user is on :0.0? I'd much rather leave that to pam_console 
than have automount reinvent that wheel.

> while the 'no-policy policy' is just as bad as setups described 
> above where your fd device file is o+rw.

The setups I described do not have the device as o+rw. Eg:

$ ls -l /dev/fd0
brw-rw----  1 paul floppy 2, 0 Feb 23 21:02 /dev/fd0

That's pam_console taking care of permissions when I login.

$ ls -l /dev/sg0
crw-rw----  1 root users 21, 0 Jul 12  2001 /dev/sg0
$ ls -l /dev/dri/card0
crw-rw----  1 root users 226, 0 Jun 23 02:57 /dev/dri/card0

$ groups
paul users

and those are statically configured group permission on a device and 
group membership.

Ok, the latter two are not mountable block devices, but they could be ;)

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
Schapiro's Explanation:
 	The grass is always greener on the other side -- but that's
 	because they use more manure.

Re: submount vs automount

[Ian Kent]

On Mon, 28 Jun 2004, Paul Jakma wrote:

> On Mon, 28 Jun 2004, Mike Waychison wrote:
> 
> > This policy has to be determined on a machine-by-machine basis.  I 
> > think we can agree to that.
> 
> Or site by site. (yeah, pam_console, eg, doesnt do directory lookups 
> for config, but hey, maybe one day)
> 
> > I just chose to examine the :0 policy because doing so allows us to 
> > explore the implications of such an implementation.
> 
> ok.
> 
> > For example, after considering the 'owner' bit, I realize now that
> > autofs would:
> >
> > - still have to parse for such an option as it runs as root and would
> > likely have to setuid to the user in question (so umount(8) still works).
> >
> > - which implies that automount would need to know who triggered the
> > mount, which isn't possible without a protocol jump.
> 
> Yes, it would. I didnt realise automount did not have access to 
> credentials of the process which triggered the 'lookup'.

This came up recently and I've given it some thought.

A pipe is used to talk from the kernel to the automount process.
So either the info must be included in the packet or the mount seperated 
from the daemon and called using a helper.

The first option requires changing the packet size and so breaks backward 
compatibility. Not necessarily bad but would need to be carefully managed.

Thinking about it, the second seems quite feasibile.

It is similar to the method to be used by Mike.

Ian