On Sat, 21 Sep 2013 17:26:48 +0200 Joshuah Hurst wrote:
> On Sat, Sep 21, 2013 at 4:31 PM, Glenn Fowler <[email protected]> wrote:
> >
> > On Sat, 21 Sep 2013 08:51:38 +0200 Lionel Cons wrote:
> >> On 19 September 2013 18:53, Roland Mainz <[email protected]> wrote:
> >> > On Thu, Sep 19, 2013 at 6:08 PM, Glenn Fowler <[email protected]>
> >> > wrote:
> >> >>
> >> >> can someone post urls for the man pages for
> >> >> readlink(1)
> >> >> realpath(1)
> >> >
> >> > 1. The relevant references:
> >> > The all-in-one manpage for busybox can be found here:
> >> > http://busybox.net/downloads/BusyBox.html
> >> >
> >> > FreeBSD readlink(1):
> >> > http://www.freebsd.org/cgi/man.cgi?query=readlink&apropos=0&sektion=1&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html
> >> > FreeBSD realpath(1):
> >> > http://www.freebsd.org/cgi/man.cgi?query=realpath&apropos=0&sektion=1&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html
> >> >
> >> > 2. Only for reference - GNU coreutils:
> >> > http://www.gnu.org/software/coreutils/manual/html_node/readlink-invocation.html
> >> > http://www.gnu.org/software/coreutils/manual/html_node/realpath-invocation.html
> >> >
> >> >> resolvepath(1)
> >> >
> >> > AFAIK that's ENOSUCHMANPAGE... out of confusion between
> >> > |resolvepath(2)| and the |*(1)| consumers of that API...
> >> > ... Lionel... can you verify this, please ?
> >
> >> Yes, that's correct. resolvepath(1) turned out to be a crazy script of
> >> our own making which gets deployed to deal with the lack of a path
> >> resolving facility - a standardisation on ksh93/busybox readlink(1)
> >> and realpath(1) would eliminate the need.
> >
> >> Please don't forget option --fd $dirfd for readlink(1) and realpath(1)
> >> so we can have a virtual root (for chroot environments without doing
> >> an actual (expensive) chroot() call each time we want to get the paths
> >> right).
> >
> > can you provide some more info on dirfd as chroot() surrogate
> > I'm a bit confused because the *at() api dirfd has no effect on absolute
> > paths
> > and the whole idea of chroot() is to grab all paths, relative and absolute
> I think the idea is to to NOT have to use chroot() each time when they
> set up a chroot environment. That doesn't include a full emulation of
> chroot behaviour, but requires to do some things relative to the
> intended root of the environment.
> I've seen such hacks before, using perl and custom wrappers for
> openat(2), fchownat(2), fstatat(2), futimesat(2), renameat(2),
> unlinkat(2) ...
perhaps I didn't phrase the question correctly
I realize that the idea is to use the chroot() fd and not chroot(2) itself
for
openat(fd, "/absolute-path", flags)
fd has no effect on the resolution of "/absolute-path" because it starts with
"/"
so
how does a chroot() emulation using *at() functions work?
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
