I've been investigating a bug report about bind mounting an autofs
controlled mount point. It is indeed disastrous for autofs. It would be
simple enough it to check and fail silently but that won't give sensible
behavior.
What should the semantics be for these type of mount requests against
autofs?
First, a move mount doesn't make sense as it places the autofs
filesystem in a location that is not specified in the autofs map to which
it belongs. It looks like the user space daemon would loose contact with
the newly mounted filesystem and so it would become useless and probably
not umountable, not to mention how the daemon would handle it. I believe
that this shouldn't be allowed. What do people think? If we don't treat
these as invalid then how should they behave?
Should there be a way for a filesystem to veto a mount request?
This doesn't appear possible atm.
This couls be done by adding a method such as "mount_begin" to match the
"umount_begin". Should the methods simply be named "mount" and "umount"
instead?
Is there a reason that the umount_begin is called only as a special case
instead of leaving it to the filesystem which implements it to decide
what needs to be done?
Bind mount requests are another question.
In the case of a bind mount we can find ourselves with a dentry in the
bound filesystem that is marked as mounted but can't be followed
because the parent vfsmount is in the source filesystem.
Should the automount functionality go along with the bind mount
filesystem? At this stage there's no straight forward way for autofs to
handle two independent mount trees from the same automount daemon. It's
just not designed to do that.
It's probably possible to make this behave as though the automounted
filesystem is mirrored under the filesystem to which it is bound. But it's
likely problematic. What do people think about this?
I've not really thought enough about recursive bind mounts yet but on
the face of it they look fairly ugly as well.
I know this post is short on detail but hopefully that will come out if
there are people interested in discussing it further.
I look forward to some feedback and hope I can find a realistic approach
to solving this problem.
Ian
> I've been investigating a bug report about bind mounting an autofs
> controlled mount point. It is indeed disastrous for autofs. It would be
> simple enough it to check and fail silently but that won't give sensible
> behavior.
>
> What should the semantics be for these type of mount requests against
> autofs?
>
> First, a move mount doesn't make sense as it places the autofs
> filesystem in a location that is not specified in the autofs map to which
> it belongs. It looks like the user space daemon would loose contact with
> the newly mounted filesystem and so it would become useless and probably
> not umountable, not to mention how the daemon would handle it. I believe
> that this shouldn't be allowed. What do people think? If we don't treat
> these as invalid then how should they behave?
Move is very similar to rbind + umount. So if you find sane semantics
for the rbind case, that should do for move as well.
> Bind mount requests are another question.
>
> In the case of a bind mount we can find ourselves with a dentry in the
> bound filesystem that is marked as mounted but can't be followed
> because the parent vfsmount is in the source filesystem.
I don't understand this. A bind will just copy a vfsmount and add the
copy to some other place in the mount tree. It should not matter if
the original mount was automounted or not. What am I missing?
> Should the automount functionality go along with the bind mount
> filesystem?
No. With bind you copy the mount to another place. Now it has
nothing to do with the automouter, it becomes a perfectly ordinary
mount.
Miklos
On Mon, 23 May 2005, Miklos Szeredi wrote:
>> I've been investigating a bug report about bind mounting an autofs
>> controlled mount point. It is indeed disastrous for autofs. It would be
>> simple enough it to check and fail silently but that won't give sensible
>> behavior.
>>
>> What should the semantics be for these type of mount requests against
>> autofs?
>>
>> First, a move mount doesn't make sense as it places the autofs
>> filesystem in a location that is not specified in the autofs map to which
>> it belongs. It looks like the user space daemon would loose contact with
>> the newly mounted filesystem and so it would become useless and probably
>> not umountable, not to mention how the daemon would handle it. I believe
>> that this shouldn't be allowed. What do people think? If we don't treat
>> these as invalid then how should they behave?
>
> Move is very similar to rbind + umount. So if you find sane semantics
> for the rbind case, that should do for move as well.
>
Perhaps not in this case.
If I read it correctly rbind is a copy of the mount tree. It leaves behind
the original. A move operation appears to copy the tree and then
basically umounts the source tree.
For autofs the originating mount point is owned and controled by the
userspace daemon and the corresponding automount map specifies what may be
mounted. We can't just umount it without cooperation from the daemon.
>> Bind mount requests are another question.
>>
>> In the case of a bind mount we can find ourselves with a dentry in the
>> bound filesystem that is marked as mounted but can't be followed
>> because the parent vfsmount is in the source filesystem.
>
> I don't understand this. A bind will just copy a vfsmount and add the
> copy to some other place in the mount tree. It should not matter if
> the original mount was automounted or not. What am I missing?
And assigns the same super block and root dentry.
The problem is that when an autofs dentry is walked on it sends a message
to the userspace daemon. The daemon performs the corresponding mount, in
the source filesystem, causing a mount to appear in the destination
filesystem as well, but without the correct vfsmount linkages.
>
>> Should the automount functionality go along with the bind mount
>> filesystem?
>
> No. With bind you copy the mount to another place. Now it has
> nothing to do with the automouter, it becomes a perfectly ordinary
> mount.
An autofs4 filesystem is intimately tied to some userspace program. For me
it's the automount daemon and the automount map defining the mountpounts
it knows about.
This is the source of the difficulty in defining the way it should behave.
Ian
> Perhaps not in this case.
Maybe I'm misunderstanding.
Are you talking about an automounted filesystem, or the autofs
filesystem itself.
With the later I can well imagine that you have problems with bind and
move.
Miklos
On Mon, 23 May 2005, Miklos Szeredi wrote:
> > Perhaps not in this case.
>
> Maybe I'm misunderstanding.
>
> Are you talking about an automounted filesystem, or the autofs
> filesystem itself.
I'm talking about the autofs filesystem (actually the autofs4 module).
>
> With the later I can well imagine that you have problems with bind and
> move.
yep.
I'm not really concerned about whether bind and move mounts work or not. I
just need to establish whether these should be supported and if so, how
they should work so I can resolve the problem. Personally, I would be
happy to say these types of mounts are not supported by autofs if I could
veto the requests.
atm I can easily panic the kernel. As I said, it would be fairly easy to
fail silently but ....
There's not much in it but see:
http://bugme.osdl.org/show_bug.cgi?id=4589
Sorry that my initial post was unclear and perhaps incomplete but mostly
people are not that familiar with automounting and often they don't really
want to know about it. I guess they have their own priorities.
Thanks for your interest.
Ian
> > > Perhaps not in this case.
> >
> > Maybe I'm misunderstanding.
> >
> > Are you talking about an automounted filesystem, or the autofs
> > filesystem itself.
>
> I'm talking about the autofs filesystem (actually the autofs4 module).
OK.
> >
> > With the later I can well imagine that you have problems with bind and
> > move.
>
> yep.
>
> I'm not really concerned about whether bind and move mounts work or not. I
> just need to establish whether these should be supported and if so, how
> they should work so I can resolve the problem. Personally, I would be
> happy to say these types of mounts are not supported by autofs if I could
> veto the requests.
Does it work if somebody renames a directory in the path leading to
the autofs mountpoint? The result is very similar to move mount.
You could solve both, by having the automoutnter daemon chdir to the
autofs root, and then it would just not care about any namespace
changes outside it's own filesystem.
Bind and clone(... CLONE_NEWNS) are trickier if you want to make
automounting work in the new instance. It should be workable, if the
autofs kernel module returns a reference not just to the dentry but
the dentry/vfsmount pair to the daemon. For example it could open a
file descriptor with dentry_open() refering to the mountpoint, and
pass that to userspace. The daemon then can do the mount on in
(either by doing fchdir(fd) and 'mount blah .', or 'mount blah
/proc/PID/fd/FD').
This is all very theoretical, I don't know how the internals of
autofs...
On a related note, have you looked at using the kernel atumounter
support for autofs? (Documentation/filesystems/automount-support.txt)
Miklos
On Tue, 24 May 2005, Miklos Szeredi wrote:
>>>> Perhaps not in this case.
>>>
>>> Maybe I'm misunderstanding.
>>>
>>> Are you talking about an automounted filesystem, or the autofs
>>> filesystem itself.
>>
>> I'm talking about the autofs filesystem (actually the autofs4 module).
>
> OK.
>
>>>
>>> With the later I can well imagine that you have problems with bind and
>>> move.
>>
>> yep.
>>
>> I'm not really concerned about whether bind and move mounts work or not. I
>> just need to establish whether these should be supported and if so, how
>> they should work so I can resolve the problem. Personally, I would be
>> happy to say these types of mounts are not supported by autofs if I could
>> veto the requests.
>
> Does it work if somebody renames a directory in the path leading to
> the autofs mountpoint? The result is very similar to move mount.
Don't know but I doubt it.
I don't think it should because autofs needs be true to the mount maps
that define what automounts are to be provided.
>
> You could solve both, by having the automoutnter daemon chdir to the
> autofs root, and then it would just not care about any namespace
> changes outside it's own filesystem.
Perhaps but I think it will not be that simple.
It's worth thinking about.
I'm working on providing full direct mount support atm (I have limited
functionality now). I will have many autofs mounts handled by a single
daemon. So that makes it a bit harder. This will be done using a file
handle to identify (for map entry lookup) each direct mount point in the
map, but still I suspect the corresponding vfsmount will end up being
wrong. I'm also thinking of doing this for indirect mounts during this
rework. A similar approach I think, to what you describe below.
I must point out that my current focus is to push the current autofs
implementation as far as it can go within its original design. Which is
probably not much further than implementing functionaly workable direct
mounts. This means that multiple namespace support is not under
consideration. Indeed the current design will not easily lend itself to
it.
Mike Waychison was working on a new version to address this and other
limitations of the current design but development of this seems to have
stopped.
>
> Bind and clone(... CLONE_NEWNS) are trickier if you want to make
> automounting work in the new instance. It should be workable, if the
> autofs kernel module returns a reference not just to the dentry but
> the dentry/vfsmount pair to the daemon. For example it could open a
> file descriptor with dentry_open() refering to the mountpoint, and
> pass that to userspace. The daemon then can do the mount on in
> (either by doing fchdir(fd) and 'mount blah .', or 'mount blah
> /proc/PID/fd/FD').
>
> This is all very theoretical, I don't know how the internals of
> autofs...
>
> On a related note, have you looked at using the kernel atumounter
> support for autofs? (Documentation/filesystems/automount-support.txt)
I saw that code when I was looking at this problem.
It looks quite interesting.
Again, I'll have to think about it.
Changes of that magnitude won't happen quickly.
It's already been a hard slog to get autofs to a reasonably stable state.
When I was looking at it I didn't see anything that would help with some
of the issues such as:
1) lazy mount/umount/expire of a tree of mount points (needs to be handled
atomically).
2) Didn't see anything relating to expire timeouts just busyness.
3) I don't think that item (1) in the file you refer to above is correct.
The nameidata struct passed to follow_link assumes that a mount point has
not been followed prior to the call. So this approach can't work for
direct mounts without some more work in the VFS. Maybe it can be done
another way but I'm not aware of it.
5) It seems that exporting the vfsmount_lock so it can be used in a
module is not good pratice (at least that was the case the last time I
needed it).
Please don't get me wrong. I did notice this code (but not the doco) and
it does look really useful to me but it means a significant redesign of
autofs. I need what's currently in place to work as it's likely to be
around for quite a while yet.
What I really need is agreement that adding a super_operations method such
as "mount" is acceptable so that I can veto bind and move mounts with the
current version. Perhaps I can do it another way ?????
Ian
==> Regarding [VFS-RFC] autofs4 and bind, rbind and move mount requests; [email protected] adds:
raven> I've been investigating a bug report about bind mounting an autofs
raven> controlled mount point. It is indeed disastrous for autofs. It would
raven> be simple enough it to check and fail silently but that won't give
raven> sensible behavior.
raven> What should the semantics be for these type of mount requests
raven> against autofs?
raven> First, a move mount doesn't make sense as it places the autofs
raven> filesystem in a location that is not specified in the autofs map to
raven> which it belongs. It looks like the user space daemon would loose
raven> contact with the newly mounted filesystem and so it would become
raven> useless and probably not umountable, not to mention how the daemon
raven> would handle it. I believe that this shouldn't be allowed. What do
raven> people think? If we don't treat these as invalid then how should
raven> they behave?
I think it is reasonable to not allow this.
[snip]
raven> Bind mount requests are another question.
raven> In the case of a bind mount we can find ourselves with a dentry in
raven> the bound filesystem that is marked as mounted but can't be followed
raven> because the parent vfsmount is in the source filesystem.
raven> Should the automount functionality go along with the bind mount
raven> filesystem? At this stage there's no straight forward way for autofs
raven> to handle two independent mount trees from the same automount
raven> daemon. It's just not designed to do that.
raven> It's probably possible to make this behave as though the automounted
raven> filesystem is mirrored under the filesystem to which it is
raven> bound. But it's likely problematic. What do people think about this?
raven> I've not really thought enough about recursive bind mounts yet but
raven> on the face of it they look fairly ugly as well.
raven> I know this post is short on detail but hopefully that will come out
raven> if there are people interested in discussing it further.
raven> I look forward to some feedback and hope I can find a realistic
raven> approach to solving this problem.
Yeah, this is really a tricky matter. On the surface, it really doesn't
make sense to me to do a mount -bind with a source directory of the
automount point. Given the current semantics of bind mounts, what does
this gain you? Likely it gains you access to an emtpy directory, or a
directory full of empty directories (in the case of ghosting).
Mount -rbind is equally nonsensical, if you agree with the last paragraph.
You will only get a copy of the vfsmount tree at the time of the mount
-rbind call. Who knows what was mounted at that time, it really isn't
deterministic.
-Jeff
> > Does it work if somebody renames a directory in the path leading to
> > the autofs mountpoint? The result is very similar to move mount.
>
> Don't know but I doubt it.
> I don't think it should because autofs needs be true to the mount maps
> that define what automounts are to be provided.
OK. Then you can just say that move mount isn't supported.
You can't stop a stupid sysadmin from messing up the system, so you
shouldn't really try.
Of course even in this case there shouldn't be anything nasty (like
Oops or panic), but I think it's OK if it simply won't work anymore.
> > You could solve both, by having the automoutnter daemon chdir to the
> > autofs root, and then it would just not care about any namespace
> > changes outside it's own filesystem.
>
> Perhaps but I think it will not be that simple.
> It's worth thinking about.
>
> I'm working on providing full direct mount support atm (I have limited
> functionality now).
Can you please explain what "direct mount" is? I'm not really
familiar with automount terminology.
> I will have many autofs mounts handled by a single daemon. So that
> makes it a bit harder. This will be done using a file handle to
> identify (for map entry lookup) each direct mount point in the map,
> but still I suspect the corresponding vfsmount will end up being
> wrong. I'm also thinking of doing this for indirect mounts during
> this rework. A similar approach I think, to what you describe below.
>
> I must point out that my current focus is to push the current autofs
> implementation as far as it can go within its original design. Which is
> probably not much further than implementing functionaly workable direct
> mounts. This means that multiple namespace support is not under
> consideration. Indeed the current design will not easily lend itself to
> it.
>
> Mike Waychison was working on a new version to address this and other
> limitations of the current design but development of this seems to have
> stopped.
I've just seen those patches (Mike pointed them out to me in another
thread).
> I saw that code when I was looking at this problem.
> It looks quite interesting.
> Again, I'll have to think about it.
> Changes of that magnitude won't happen quickly.
> It's already been a hard slog to get autofs to a reasonably stable state.
>
> When I was looking at it I didn't see anything that would help with some
> of the issues such as:
>
> 1) lazy mount/umount/expire of a tree of mount points (needs to be handled
> atomically).
> 2) Didn't see anything relating to expire timeouts just busyness.
> 3) I don't think that item (1) in the file you refer to above is correct.
> The nameidata struct passed to follow_link assumes that a mount point has
> not been followed prior to the call. So this approach can't work for
> direct mounts without some more work in the VFS. Maybe it can be done
> another way but I'm not aware of it.
> 5) It seems that exporting the vfsmount_lock so it can be used in a
> module is not good pratice (at least that was the case the last time I
> needed it).
>
> Please don't get me wrong. I did notice this code (but not the doco) and
> it does look really useful to me but it means a significant redesign of
> autofs. I need what's currently in place to work as it's likely to be
> around for quite a while yet.
I'm not too familiar with that code either, and I'm not trying to
convince you either way :)
I think it does address the atomicity issue, but requires special
do_add_mount() call (which places the vfsmount on the expiry list), so
it probably needs some work to export that functionality to userspace
mounts.
> What I really need is agreement that adding a super_operations method such
> as "mount" is acceptable so that I can veto bind and move mounts with the
> current version. Perhaps I can do it another way ?????
If you just want to disable bind (so that it doesn't cause trouble),
the simplest way seems to be to remember the original vfsmount, and
just ignore any lookups in other vfsmounts. You can do this, since
the vfsmount is passed in the nameidata parameter of dir->lookup().
Then bind will succeed, but the autofs will simply not do anything in
the copied mount. I think that would be much cleaner than trying to
veto a bind request.
Miklos
On Tue, 24 May 2005, Miklos Szeredi wrote:
> > > Does it work if somebody renames a directory in the path leading to
> > > the autofs mountpoint? The result is very similar to move mount.
> >
> > Don't know but I doubt it.
> > I don't think it should because autofs needs be true to the mount maps
> > that define what automounts are to be provided.
>
> OK. Then you can just say that move mount isn't supported.
>
> You can't stop a stupid sysadmin from messing up the system, so you
> shouldn't really try.
>
> Of course even in this case there shouldn't be anything nasty (like
> Oops or panic), but I think it's OK if it simply won't work anymore.
>
> > > You could solve both, by having the automoutnter daemon chdir to the
> > > autofs root, and then it would just not care about any namespace
> > > changes outside it's own filesystem.
> >
> > Perhaps but I think it will not be that simple.
> > It's worth thinking about.
> >
> > I'm working on providing full direct mount support atm (I have limited
> > functionality now).
>
> Can you please explain what "direct mount" is? I'm not really
> familiar with automount terminology.
The mounts appear in a map whose source can be a file or NIS or other
supported repositiry. A master map tells autofs where to find the actual
mount maps.
All automount maps can be classified as either indirect or direct.
An indirect map looks like:
in the master map
/home /etc/auto.home
in auto.home
user1 server1:/home/user1
user2 server1:/home/otheruser
and so on.
A direct map looks like
in the master map
/- /etc/auto.direct
in auto.direct
/usr/share/man server:/usr/share/${OSNAME}-${OSVER}/man
/nfs/thishost/thisdata anotherserver:/local/data/thisdata
and so on.
There are other things that can be used in maps such as wild card key
matching and substitution and the like.
>
> > I will have many autofs mounts handled by a single daemon. So that
> > makes it a bit harder. This will be done using a file handle to
> > identify (for map entry lookup) each direct mount point in the map,
> > but still I suspect the corresponding vfsmount will end up being
> > wrong. I'm also thinking of doing this for indirect mounts during
> > this rework. A similar approach I think, to what you describe below.
> >
> > I must point out that my current focus is to push the current autofs
> > implementation as far as it can go within its original design. Which is
> > probably not much further than implementing functionaly workable direct
> > mounts. This means that multiple namespace support is not under
> > consideration. Indeed the current design will not easily lend itself to
> > it.
> >
> > Mike Waychison was working on a new version to address this and other
> > limitations of the current design but development of this seems to have
> > stopped.
>
> I've just seen those patches (Mike pointed them out to me in another
> thread).
>
> > I saw that code when I was looking at this problem.
> > It looks quite interesting.
> > Again, I'll have to think about it.
> > Changes of that magnitude won't happen quickly.
> > It's already been a hard slog to get autofs to a reasonably stable state.
> >
> > When I was looking at it I didn't see anything that would help with some
> > of the issues such as:
> >
> > 1) lazy mount/umount/expire of a tree of mount points (needs to be handled
> > atomically).
> > 2) Didn't see anything relating to expire timeouts just busyness.
> > 3) I don't think that item (1) in the file you refer to above is correct.
> > The nameidata struct passed to follow_link assumes that a mount point has
> > not been followed prior to the call. So this approach can't work for
> > direct mounts without some more work in the VFS. Maybe it can be done
> > another way but I'm not aware of it.
> > 5) It seems that exporting the vfsmount_lock so it can be used in a
> > module is not good pratice (at least that was the case the last time I
> > needed it).
> >
> > Please don't get me wrong. I did notice this code (but not the doco) and
> > it does look really useful to me but it means a significant redesign of
> > autofs. I need what's currently in place to work as it's likely to be
> > around for quite a while yet.
>
> I'm not too familiar with that code either, and I'm not trying to
> convince you either way :)
>
> I think it does address the atomicity issue, but requires special
> do_add_mount() call (which places the vfsmount on the expiry list), so
> it probably needs some work to export that functionality to userspace
> mounts.
>
> > What I really need is agreement that adding a super_operations method such
> > as "mount" is acceptable so that I can veto bind and move mounts with the
> > current version. Perhaps I can do it another way ?????
>
> If you just want to disable bind (so that it doesn't cause trouble),
> the simplest way seems to be to remember the original vfsmount, and
> just ignore any lookups in other vfsmounts. You can do this, since
> the vfsmount is passed in the nameidata parameter of dir->lookup().
>
> Then bind will succeed, but the autofs will simply not do anything in
> the copied mount. I think that would be much cleaner than trying to
> veto a bind request.
Not sure that will be without pain down the track from a support
viewpoint.
Thanks for your advice
Ian