Re: "broken" symbolic links in /usr/lib
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
Glen Barber wrote: > On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: > > 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)? > > Your explanation makes sense to me. The cause of this, however is > unclear - was this something done locally? This is why I asked about > the permissions of '/lib', but based on what you've explained, even > asking for the permissions of '/usr' would not have led to a clear > answer. I think the cause was when I moved to an SSD in this laptop and created the filesystems on the new disk by hand. > So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? > Or is this not the case? This is exactly the case. What's confusing is the inconsistent use of the '/usr' (unmounted) and '/usr' (mounted) modes depending on circumstance. ie, non-root can cd and ls to '/usr' (mounted), but not '/usr' (unmounted), but can't resolve a relative symlink in that path. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
On 29/07/2015 05:48, Jamie Landeg-Jones wrote: > Gary Palmer wrote: > >> As best that I can recall, the permissions of the directory underneath >> the mount point has been causing problems like this for as long as I've been >> using FreeBSD, which is over 20 years at this point. It's certainly >> bit me in the distant past. > > I concur. I always make mount point directories 0111,noschg,nodump - it makes > them stand out when not mounted, and also stops accidental directory deletion > potentially stopping a reboot from working. > > But yeah, for 20+ years. I've also experienced problems if a mount-point > directory doesn't have +x access. A long time ago -- before the millenium -- NeXT machines did away with the need for a mount-point directory to exist. So, if you wanted to mount /foo/bar, only the /foo directory needed to exist prior to the mount. Since NeXT was subsumed by Apple, and NeXTStep reborn as MacOSX, the same is presumably true today all Macs. (Although I haven't tested this personally.) I do wonder why the rest of the world didn't do likewise. It would make this sort of problem a non-event. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: "broken" symbolic links in /usr/lib
Gary Palmer wrote: > As best that I can recall, the permissions of the directory underneath > the mount point has been causing problems like this for as long as I've been > using FreeBSD, which is over 20 years at this point. It's certainly > bit me in the distant past. I concur. I always make mount point directories 0111,noschg,nodump - it makes them stand out when not mounted, and also stops accidental directory deletion potentially stopping a reboot from working. But yeah, for 20+ years. I've also experienced problems if a mount-point directory doesn't have +x access. Cheers, Jamie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: [trim] > 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? As best that I can recall, the permissions of the directory underneath the mount point has been causing problems like this for as long as I've been using FreeBSD, which is over 20 years at this point. It's certainly bit me in the distant past. Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: > 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)? > Your explanation makes sense to me. The cause of this, however is unclear - was this something done locally? This is why I asked about the permissions of '/lib', but based on what you've explained, even asking for the permissions of '/usr' would not have led to a clear answer. So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? Or is this not the case? Glen pgpiIBFxPtvK1.pgp Description: PGP signature
Re: "broken" symbolic links in /usr/lib
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
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
Glen Barber wrote: > On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: > > On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > > > Hi > > >=20 > > > I cannot for the life of me figure out why this is so: > > >=20 > > > As non-root: > > > [zen] /usr/lib $ file libgcc_s.so > > > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 > > >=20 > > > As root: > > > [zen] /usr/lib # file libgcc_s.so=20 > > > libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 > > >=20 > > > Only on one of my machines, all running CURRENT from within a day. > > > The upshot is that I have to be root in order to link code. > > >=20 > > > Any ideas greatly appreciated. > > >=20 > >=20 > > What are the permissions on /lib/libgcc_s.so.1 ? > >=20 > > Probably a better question: What are the permissions on /lib ? Answering both: [zen] /usr/lib # ls -ld /lib drwxr-xr-x 3 root wheel 1536 Jul 28 19:07 /lib [zen] /usr/lib # ls -l /lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 57792 Jul 28 19:07 /lib/libgcc_s.so.1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: > On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > > Hi > > > > I cannot for the life of me figure out why this is so: > > > > As non-root: > > [zen] /usr/lib $ file libgcc_s.so > > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 > > > > As root: > > [zen] /usr/lib # file libgcc_s.so > > libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 > > > > Only on one of my machines, all running CURRENT from within a day. > > The upshot is that I have to be root in order to link code. > > > > Any ideas greatly appreciated. > > > > What are the permissions on /lib/libgcc_s.so.1 ? > Probably a better question: What are the permissions on /lib ? Glen pgpSXc3KQXxR0.pgp Description: PGP signature
Re: "broken" symbolic links in /usr/lib
On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > Hi > > I cannot for the life of me figure out why this is so: > > As non-root: > [zen] /usr/lib $ file libgcc_s.so > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 > > As root: > [zen] /usr/lib # file libgcc_s.so > libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 > > Only on one of my machines, all running CURRENT from within a day. > The upshot is that I have to be root in order to link code. > > Any ideas greatly appreciated. > What are the permissions on /lib/libgcc_s.so.1 ? Glen pgpGfBlmv_TIa.pgp Description: PGP signature
Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
On Tue, May 22, 2012 2:27 pm, Jeremie Le Hen wrote: > This is expected I think, as "make buildenv" defines $_SHLIBDIRPREFIX > which is used to make the toolchain use libraries built during stage 4.2 > of buildworld. > > Just run "make installworld" with the correct DESTDIR and your chroot > will be fine. > It helped! Thank you very much! -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
Ilya, On Mon, May 21, 2012 at 01:43:39PM +0200, Ilya Bakulin wrote: > On Mon, May 21, 2012 12:36 pm, Jeremie Le Hen wrote: > > Can you provide the exact commands you have used to create your chroot? > > > Sure! > > 1. The build host is FreeBSD 8.2-RELEASE-p3 amd64 > 2. Directory where project resides ($PROJROOT): > /home/kibab/repos/freebsd-cap-git > 2. FreeBSD-CURRENT sources are in $PROJROOT/freebsd > 3. Object directory is $PROJROOT/obj > 4. Installation directory is $PROJROOT/inst > > 5. Building world: while in $PROJROOT/freebsd, I type: > make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 > buildworld > ...After a while, build ends... > 6. while in $PROJROOT/freebsd, type `sudo make buildenv`, after entering > build environment I set nessesary env variables: > PROJROOT=/home/kibab/repos/freebsd-cap-git > MAKEOBJDIRPREFIX=/home/kibab/repos/freebsd-cap-git/obj > DISTDIR=/home/kibab/repos/freebsd-cap-git/inst > DESTDIR=/home/kibab/repos/freebsd-cap-git/inst > > 7. After that, type: > make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 > installworld This is expected I think, as "make buildenv" defines $_SHLIBDIRPREFIX which is used to make the toolchain use libraries built during stage 4.2 of buildworld. Just run "make installworld" with the correct DESTDIR and your chroot will be fine. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
On Mon, May 21, 2012 12:36 pm, Jeremie Le Hen wrote: > Can you provide the exact commands you have used to create your chroot? > Sure! 1. The build host is FreeBSD 8.2-RELEASE-p3 amd64 2. Directory where project resides ($PROJROOT): /home/kibab/repos/freebsd-cap-git 2. FreeBSD-CURRENT sources are in $PROJROOT/freebsd 3. Object directory is $PROJROOT/obj 4. Installation directory is $PROJROOT/inst 5. Building world: while in $PROJROOT/freebsd, I type: make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 buildworld ...After a while, build ends... 6. while in $PROJROOT/freebsd, type `sudo make buildenv`, after entering build environment I set nessesary env variables: PROJROOT=/home/kibab/repos/freebsd-cap-git MAKEOBJDIRPREFIX=/home/kibab/repos/freebsd-cap-git/obj DISTDIR=/home/kibab/repos/freebsd-cap-git/inst DESTDIR=/home/kibab/repos/freebsd-cap-git/inst 7. After that, type: make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 installworld Now I can chroot to newly installed system. FreeBSD 8.2 still allows running 10-CURRENT binaries, so that's not a problem: kibab@ssh%pwd /home/kibab/repos/freebsd-cap-git/inst kibab@ssh%sudo chroot `pwd` /bin/csh # ls -l /usr/lib | grep libgcc_s lrwxr-xr-x 1 0 0 71 May 20 17:31 libgcc_s.so -> /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libgcc_s.so.1 So the path to shared library is invalid! This setup was functional for about a year, and it was broken by recent update. I tried with clean object directory as well, this doesn't change anything. -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
Hi, On Sun, May 20, 2012 at 07:54:22PM +0200, Ilya Bakulin wrote: > Hi all, > I have compiled FreeBSD-CURRENT amd64 (fresh checkout from today, git > revision 46b12ff6d8ab4f736d155646ae32133083e1da05 -- from official > FreeBSD github mirror) and installed it in custom location (DESTDIR= > make installworld). > > After chrooting to installed system and trying to compile any program I > get the message: > > # gcc -o hello hello.c > /usr/bin/ld: cannot find -lgcc_s > > Here is an output of 'ls -l' after chrooting to installed system: > > total 89076 > -rwxr-xr-x 1 0 0 3352 19 ?? 21:27 Scrt1.o > drwxr-xr-x 2 0 0 512 20 ?? 08:39 aout > drwxr-xr-x 3 0 0 512 20 ?? 08:39 compat > -rwxr-xr-x 1 0 0 3296 19 ?? 21:27 crt1.o > -rwxr-xr-x 1 0 0 2408 19 ?? 21:27 crtbegin.o > ... > -rwxr-xr-x 1 0 0 56354 20 ?? 09:31 libalias.a > lrwxr-xr-x 1 0 0 71 20 ?? 09:54 libalias.so -> > /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libalias.so.7 > -rwxr-xr-x 1 0 0 3200 20 ?? 09:31 libalias_cuseeme.a > ... > -rwxr-xr-x 1 0 0 17108 20 ?? 09:31 libbegemot.a > lrwxr-xr-x 1 0 0 73 20 ?? 09:54 libbegemot.so -> > /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libbegemot.so.4 > ... > lrwxr-xr-x 1 root wheel 71 20 ?? 21:31 libgcc_s.so -> > /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libgcc_s.so.1 > > Links to libalias, libbegemot, libgcc_s point to respective libraries > under /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib. But > this path doesn't exist even on build system! > In my setup, FreeBSD source tree is under > /home/kibab/repos/freebsd-cap-git/freebsd, object directory is > /home/kibab/repos/freebsd-cap-git/freebsd/obj, installation directory is > /home/kibab/repos/freebsd-cap-git/freebsd/inst. > As I understand, this problem will arise only if using non-standard > object directory (not under /usr/obj), because symbolic links will > otherwise point to some files under /usr/obj and required files will be > actually there. This is still incorrect, but at least would seem to work... > > I'm using custom src.conf with these options: > WITHOUT_CLANG=yes > WITHOUT_GAMES=yes > WITHOUT_KERNEL_SYMBOLS=yes > WITHOUT_EXAMPLES=yes > WITHOUT_HTML=yes > WITHOUT_NCP=yes > WITHOUT_PROFILE=yes > WITHOUT_SENDMAIL=yes > WITHOUT_SYSINSTALL=yes > WITHOUT_VINUM=yes > WITHOUT_LIB32=yes > > I tried a fresh build with clean object directory. > Could anyone tell what may have gone wrong? Can you provide the exact commands you have used to create your chroot? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
