On 10/08/2013 03:03:03 AM, Karel Zak wrote:
On Sat, Oct 05, 2013 at 06:42:44PM -0500, Rob Landley wrote:
> Oh, attached is a dumb "zapchroot" script I've been using for years
to
> unlink all mount points under a given directory, taking advantage
of the
> fact that mount points are appended to
On Sat, Oct 05, 2013 at 06:42:44PM -0500, Rob Landley wrote:
> Oh, attached is a dumb "zapchroot" script I've been using for years to
> unlink all mount points under a given directory, taking advantage of the
> fact that mount points are appended to the end of the list so if you unlink
> from the e
Rob Landley writes:
> On 10/04/2013 07:03:23 PM, Eric W. Biederman wrote:
>>
>> In principle I have no problems tweaking rmdir to check for that case.
>>
>> At the same time the real reason that this is safe is that mount
>> points
>> are almost always part of trusted paths to important files
On Sat, Oct 5, 2013 at 5:18 PM, Rob Landley wrote:
>
> Which is why containers have all sorts of extra plumbing. But that extra
> plumbing is currently built on pivot_root(), not on chroot(). And I'd
> dismissed pivot_root() as residue from initramfs with all that kernel thread
> reparenting, so i
On 10/05/2013 06:24:51 PM, Al Viro wrote:
On Sat, Oct 05, 2013 at 04:17:55PM -0700, Linus Torvalds wrote:
> On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley wrote:
> >
> > A todo item I've had _forever_ is fixing chroot() to not be
broken so that
> > you can trivially break out of a chroot via:
>
On 10/05/2013 06:22:15 PM, Linus Torvalds wrote:
On Sat, Oct 5, 2013 at 4:17 PM, Linus Torvalds
wrote:
>
> So learn this pattern: every time you use chroot, add a simple
>
> chdir("/");
>
> immediately after the chroot call.
.. btw, also make sure that you close all non-essential file
descrip
On 10/05/2013 06:19:15 PM, Al Viro wrote:
On Sat, Oct 05, 2013 at 06:07:42PM -0500, Rob Landley wrote:
> A todo item I've had _forever_ is fixing chroot() to not be broken
> so that you can trivially break out of a chroot via:
>
> chdir("/");
> mkdir("sub");
> chroot("sub");
> chdir("./..
On 10/05/2013 06:17:55 PM, Linus Torvalds wrote:
On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley wrote:
>
> A todo item I've had _forever_ is fixing chroot() to not be broken
so that
> you can trivially break out of a chroot via:
What drugs are you on?
Enough caffeine to count as a plural.
Y
On 10/04/2013 07:03:23 PM, Eric W. Biederman wrote:
Linus Torvalds writes:
> On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman
wrote:
>>
>> After thinking about it removing the restrictions on mount points
>> appears safe, because it is just plain dumb to have a mount point
>> in a director
On Sat, Oct 05, 2013 at 04:17:55PM -0700, Linus Torvalds wrote:
> On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley wrote:
> >
> > A todo item I've had _forever_ is fixing chroot() to not be broken so that
> > you can trivially break out of a chroot via:
>
> What drugs are you on?
>
> Your example is
On Sat, Oct 5, 2013 at 4:17 PM, Linus Torvalds
wrote:
>
> So learn this pattern: every time you use chroot, add a simple
>
> chdir("/");
>
> immediately after the chroot call.
.. btw, also make sure that you close all non-essential file
descriptors. Having any open directory file descriptors po
On Sat, Oct 05, 2013 at 06:07:42PM -0500, Rob Landley wrote:
> A todo item I've had _forever_ is fixing chroot() to not be broken
> so that you can trivially break out of a chroot via:
>
> chdir("/");
> mkdir("sub");
> chroot("sub");
> chdir("./../../../../../../../..");
>
> (Because chro
On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley wrote:
>
> A todo item I've had _forever_ is fixing chroot() to not be broken so that
> you can trivially break out of a chroot via:
What drugs are you on?
Your example is moronic, and against all _documented_ uses of chroot.
> chdir("/");
> mkdir
On 10/04/2013 05:41:25 PM, Eric W. Biederman wrote:
This patchset is an attempt to address two problems:
1) Not all modifications to the filesystems happen through the vfs and
since the vfs can not cope with a mount point being unlinked or
renamed filesystems whose modifications that do no
ebied...@xmission.com (Eric W. Biederman) writes:
> I just noticed that Al's latest vfs changes posted yesterday mean I need
> to rebase and possibly respin these patches, as all of the locking and
> interesting bits of the dcache have changed. I don't think the
> conflicts would be fun to resolv
Linus Torvalds writes:
> On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman
> wrote:
>>
>> After thinking about it removing the restrictions on mount points
>> appears safe, because it is just plain dumb to have a mount point
>> in a directory that is not restricted to root only modifications.
>
On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman wrote:
>
> After thinking about it removing the restrictions on mount points
> appears safe, because it is just plain dumb to have a mount point
> in a directory that is not restricted to root only modifications.
>
> This is a change in user visibl
This patchset is an attempt to address two problems:
1) Not all modifications to the filesystems happen through the vfs and
since the vfs can not cope with a mount point being unlinked or
renamed filesystems whose modifications that do not come through the
vfs are required to lie.
2) Thr
18 matches
Mail list logo
