Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Aug 2011 10:23:32 -0600
From:      "Justin T. Gibbs" <gibbs@FreeBSD.org>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r224901 - projects/zfsd/head/sys/fs/devfs
Message-ID:  <4E4A9984.2040305@FreeBSD.org>
In-Reply-To: <20110816124102.GA1674@garage.freebsd.pl>
References:  <201108160435.p7G4ZgNO041036@svn.freebsd.org> <20110816124102.GA1674@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8/16/11 6:41 AM, Pawel Jakub Dawidek wrote:
>  On Tue, Aug 16, 2011 at 04:35:42AM +0000, Justin T. Gibbs wrote:
> > Author: gibbs
> > Date: Tue Aug 16 04:35:42 2011
> > New Revision: 224901
> > URL: http://svn.freebsd.org/changeset/base/224901
> >
> > Log:
> > Correct the rendering of device aliases that reside in subdirectories
> > of a devfs.
> >
> > devfs/devfs_vnops.c:
> > In devfs_readlink(), convert the devfs root relative path
> > of an alias's parent, that is recorded in the alias, into a
> > fully qualified path that includes the root of the containing
> > devfs. This avoids the ugliness of generating a relative path
> > by prepending "../"'s. For a non-jailed process, the "symlink
> > root" is the devfs's mount point. For a jailed process, we
> > must remove any jail prefix in the mount point so that our
> > response matches the user process's world view.
>
>  Note that currently realpath for both mount point and jail root is
>  resolved by userland tools (mount(8) and jail(8)). It is still possible
>  that someone will use nmount(2) or jail(2) system calls directly and
>  will pass not a realpath, but something else (eg. ../../foo/bar).
>  Because of this simple strncmp() is no reliable.

There is at least one other location in the kernel that make similar
similar assumptions to those made in my changes to devfs_readlink():
prison_canseemount().  I'm sure there are others.

>  The given paths should be resolved for those syscalls within the 
kernel using
>  vn_fullpath_global(), then it would be more reliable.

By "those syscalls", you mean nmount(2) and jail(8)?  It would be nice
to contain the "canonicalization logic" to as few places as possible or
provide a clean API to do these conversions.

>  It still won't work when file system is mount, then its parent
>  directory is renamed and jail created on now different path

I can't quite parse what you mean here.  Can you provide an example?

Thanks,
Justin




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4A9984.2040305>