Should mount --bind not follow symlinks?

Should mount --bind not follow symlinks?

[Anthony Heading]

Hi,
    My automounted dirs have up till now been symlinks, where
e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST
which is a symlink.

   This all worked OK until the 2.4(.2) automounter helpfully tries
to mount --bind /export/opt/perl/LATEST /opt/perl

   And this errors with "mount: wrong fs type, ..." because it
seems the first arg to mount --bind mustn't be a symlink,
resulting in a "No such file" or similar error being returned
to the requester.

   What is especially confusing is that if this whole thing
was kicked off with say  ls /opt/perl/bin,  the first attempt
returns "No such file or directory", but automount
then installs a symlink into /opt,  so a second ls attempt
works fine.

   Is this known about / to be expected?  I can't see why
one of automount or mount or the underlying system call
shouldn't chase symlinks, but I know I might be missing
some reason why I shouldn't be attempting this.

Anthony

Re: Should mount --bind not follow symlinks?

[Alexander Viro]

On Mon, 12 Mar 2001, Anthony Heading wrote:

> Hi,
>     My automounted dirs have up till now been symlinks, where
> e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST
> which is a symlink.
> 
>    This all worked OK until the 2.4(.2) automounter helpfully tries
> to mount --bind /export/opt/perl/LATEST /opt/perl

Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
been deliberately prohibited. You _really_ don't want to handle the
broken symlinks and all the realted fun - race-ridden at extreme and
useless.

In automount-like setups you can _replace_ symlinks with bindings.
No need to mix them.
							Cheers,
								Al

Re: Should mount --bind not follow symlinks?

[Anthony]

Alexander Viro wrote:
> Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
> been deliberately prohibited. You _really_ don't want to handle the
> broken symlinks and all the realted fun [...]

No. But I hoped _you_ might :-)

> - race-ridden at extreme and useless.
> In automount-like setups you can _replace_ symlinks with bindings.
> No need to mix them.

Hmm.  My /etc/auto.opt contains

*       :/export/opt/&/LATEST

where all the "LATEST"s etc are symlinks.  I found it quite
an elegant way to maintain different versions: the symlink
was de-facto a trivially simple version database.

Does the version state now *have* to be listed in
/etc/auto.opt explicitly?  That feels a little retrograde.

Perhaps I'm blissfully unaware of all sorts of vile
race conditions, but why can't the *automounter* chase
the symlinks even if mount shouldn't?  Or am I missing
a neater solution?

Rgds

Anthony

Re: Should mount --bind not follow symlinks?

[Jamie Lokier]

Anthony wrote:
> Perhaps I'm blissfully unaware of all sorts of vile
> race conditions, but why can't the *automounter* chase
> the symlinks even if mount shouldn't?  Or am I missing
> a neater solution?

The automounter could indeed chase those symlinks.

Also, if the automounter creates a symlink in /opt anyway, and the link
subsequently works (as you said), then it shouldn't be returning "No
such file or directory" the first time.

In other words the latter behaviour looks like a bug in the automounter,
and the former is a feature which could be added but isn't needed for
your application.

-- Jamie

Re: Should mount --bind not follow symlinks?

[Anthony]

Jamie Lokier wrote:
> The automounter could indeed chase those symlinks.
> 
> Also, if the automounter creates a symlink in /opt anyway, and the link
> subsequently works (as you said), then it shouldn't be returning "No
> such file or directory" the first time.
> 
> In other words the latter behaviour looks like a bug in the automounter,
> and the former is a feature which could be added but isn't needed for
> your application.

Okay!  Well, the following I think fixes everything for me, as a 
small tweak to autofs-4.0.0pre9.

Thanks

Anthony


*** modules/mount_bind.c.Orig   Sun Mar 25 15:43:27 2001
--- modules/mount_bind.c        Mon Mar 26 22:57:10 2001
***************
*** 19,24 ****
--- 19,25 ----
  #include <errno.h>
  #include <fcntl.h>
  #include <unistd.h>
+ #include <stdlib.h>
  #include <syslog.h>
  #include <string.h>
  #include <sys/param.h>
***************
*** 71,76 ****
--- 72,84 ----
    char *fullpath;
    int err;
    int i;
+ 
+   char real[PATH_MAX];
+   if (!realpath(what, real)) {
+     syslog(LOG_NOTICE, MODPREFIX "realpath %s failed: %m", what);
+     return 1;
+   }
+   what = real;
  
    fullpath = alloca(strlen(root)+name_len+2);
    if ( !fullpath ) {

Re: Should mount --bind not follow symlinks?

[Kai Henningsen]

viro@math.psu.edu (Alexander Viro)  wrote on 12.03.01 in <Pine.GSO.4.21.0103120835390.25792-100000@weyl.math.psu.edu>:

> On Mon, 12 Mar 2001, Anthony Heading wrote:
>
> > Hi,
> >     My automounted dirs have up till now been symlinks, where
> > e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST
> > which is a symlink.
> >
> >    This all worked OK until the 2.4(.2) automounter helpfully tries
> > to mount --bind /export/opt/perl/LATEST /opt/perl
>
> Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
> been deliberately prohibited. You _really_ don't want to handle the
> broken symlinks and all the realted fun - race-ridden at extreme and
> useless.

Race? Where? You resolve the symlink once and operate on the result. No  
need to remember anywhere that it ever was a symlink. If there *can* be a  
race, this sounds like a serious design bug.

This looks like it *seriously* breaks my current 2.2 setup: I have dirs  
with sensible names under /Partition, and symlinks to those dirs whose  
name is the UUID for mount to use. Nothing automount in here. (And of  
course all those links and directories are completely static and only root- 
modifiable anyway, this only changes when I repartition.)

MfG Kai