namei and path canonicalization

2017-11-07 Thread David Holland
Currently namei is supposed to canonicalize paths as it processes them. It turns out that this is broken and has been for some time (likely since before -6) -- also the feature is a significant source of complexity and does not really serve any useful purpose. Therefore, I'd like to remove it. The

Re: namei and path canonicalization

2017-11-07 Thread David Holland
On Tue, Nov 07, 2017 at 10:20:27PM +, David Holland wrote: > First of all, there is no need to provide a canonicalized path in > $ORIGIN, just a path. The victim^W application can call realpath() > itself if it cares for some reason. It is sufficient to provide either > the path passed to e

Re: namei and path canonicalization

2017-11-07 Thread Christos Zoulas
In article <20171107222924.ge17...@netbsd.org>, David Holland wrote: > >Also it occurs to me that there's no reason for the kernel to do the >getcwd call; it should just provide the argument given to exec in all >cases, and ld.so can do the getcwd call itself if necessary (if the >string it finds

Re: namei and path canonicalization

2017-11-07 Thread Paul Goyette
On Tue, 7 Nov 2017, Christos Zoulas wrote: We provide the full path currently via AT_SUN_EXECNAME, sysctl, and procfs. I think this is currently broken, at least when the path is "below" a null-mount, such as when running inside a chroot sandbox? +--+--

Re: namei and path canonicalization

2017-11-07 Thread David Holland
On Wed, Nov 08, 2017 at 07:23:48AM +0800, Paul Goyette wrote: > > > We provide the full path currently via AT_SUN_EXECNAME, sysctl, and > > procfs. > > I think this is currently broken, at least when the path is "below" a > null-mount, such as when running inside a chroot sandbox? After to

Re: namei and path canonicalization

2017-11-07 Thread David Holland
On Tue, Nov 07, 2017 at 11:11:16PM +, Christos Zoulas wrote: > In article <20171107222924.ge17...@netbsd.org>, > David Holland wrote: > > > >Also it occurs to me that there's no reason for the kernel to do the > >getcwd call; it should just provide the argument given to exec in all > >c

Re: namei and path canonicalization

2017-11-07 Thread Christos Zoulas
On Nov 8, 3:12am, dholland-t...@netbsd.org (David Holland) wrote: -- Subject: Re: namei and path canonicalization | On Tue, Nov 07, 2017 at 11:11:16PM +, Christos Zoulas wrote: | > In article <20171107222924.ge17...@netbsd.org>, | > David Holland wrote: | > > | >

Re: namei and path canonicalization

2017-11-07 Thread David Holland
On Tue, Nov 07, 2017 at 10:30:38PM -0500, Christos Zoulas wrote: > On Nov 8, 3:12am, dholland-t...@netbsd.org (David Holland) wrote: > -- Subject: Re: namei and path canonicalization > > | On Tue, Nov 07, 2017 at 11:11:16PM +, Christos Zoulas wrote: > | > In artic

Re: namei and path canonicalization

2017-11-08 Thread Edgar Fuß
> remembering the directory vnode the program was exec'd from > and providing a way to open it as a file handle. Plus some extra measures so you can't escape to there after a chroot(), no?

Re: namei and path canonicalization

2017-11-08 Thread Christos Zoulas
On Nov 8, 6:54am, dholland-t...@netbsd.org (David Holland) wrote: -- Subject: Re: namei and path canonicalization | We don't, at least as of your changes this afternoon which always set | it... I'm wondering if we should though. Any setugid program that uses | that value is presumpti