Date: Wed, 29 Jul 2015 09:34:36 -0600 From: Ian Lepore <ian@freebsd.org> To: Ian FREISLICH <ian.freislich@capeaugusta.com> Cc: David Wolfskill <david@catwhisker.org>, current@freebsd.org Subject: Re: "broken" symbolic links in /usr/lib Message-ID: <1438184076.1234.22.camel@freebsd.org> In-Reply-To: <E1ZKBJi-0000JZ-FS@clue.co.za> References: <20150728200034.GO1277@albert.catwhisker.org> <20150728184516.GN1277@albert.catwhisker.org> <E1ZK9QG-000CAR-KW@clue.co.za> <E1ZKAuN-000CK7-MG@clue.co.za> <E1ZKBJi-0000JZ-FS@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-07-28 at 22:17 +0200, Ian FREISLICH wrote:
> David Wolfskill wrote:
> > My experience with SU+J is limited (and negative -- in large part,
> > because I tend heavily on "dump | restore" pipelines to copy file
> > systems, some of which are "live" at the time (danger mitigated by -L
> > flag for dump).
>
> As an aside, mine has been pretty positive, except for once having
> / moved entirely to /lost+found and encoded as inode numbers. That
> might be enough for some.
>
> > If you can take that system down, I suggest:
> >
> > * Reboot to single-user mode.
> >
> > * Disable SU journaling ("tunefs -j disable $special")
> >
> > * fsck -p / (at least; possibly elide the "-p")
> >
> > * If you want SU+J, re-enable it ("tunefs -j enable $special")
> >
> > * While theory says "exit" at this point should just continue the
> > transition to multi-user mode, I'd be inclined to just reboot & watch it
> > to make sure nothing "weird" happens that you don't know about.
> >
> > * Re-test.
>
> So, a couple of fscks found some problems, but none causing this.
>
> I found the actual problem. The mount point for /usr was mode 700
> even though the root of the mounted filesystem on /usr was mode 755.
> Did I explain that clearly (quite difficult because two things are
> the same thing, although they're apparently not)?
>
> Seems that for some reason, some but not all actions involving the
> transition between . and .. on the mount point use either the
> permissions of the mount point or the permissions of the directory
> mounted on that mount point. In the past, the permissions in the
> mounted filesystem have always trumped the mount point, but I have
> no idea what the spec says. Is this a bug?
>
> Ian
>
I suspect that a combination of symlinks (which often use multiple
levels of ../ to traverse filesystems) and this caveat from the mount(8)
manpage explain what you see...
CAVEATS
After a successful mount, the permissions on the original mount point
determine if .. is accessible from the mounted file system. The minimum
permissions for the mount point for traversal across the mount point in
both directions to be possible for all users is 0111 (execute for all).
It makes a kind of sense when you think about it. To access ../ from
the root of a mounted filesystem you have to read the underlying mount
point directory to see what its parent is, and that requires access to
that directory.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1438184076.1234.22.camel>