Bill Davidsen wrote:
It seems there are (at least) two parts to this, one regarding
changing working directory which is clearly stated in the standards
and must work as it does, and the various issues regarding getting out
of the chroot after the cwd has entered that changed root. That second
Theodore Tso wrote:
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
So the OpenBSD man page seems to be in the minority here. Any portable
code can not assume that CWD changes. And changing the Linux behaviour
now would be a rather big change which might break userspace.
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
> So the OpenBSD man page seems to be in the minority here. Any portable
> code can not assume that CWD changes. And changing the Linux behaviour
> now would be a rather big change which might break userspace. And yes,
> there
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot,
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote:
> Adrian Bunk wrote:
>> You claimed:
>>
>> <-- snip -->
>>
>> Look, when chroot was being designed, I think they intended that even root
>> should be unable to get out. They went so far as to say that dot-dot
>> wouldn't let you
Adrian Bunk wrote:
You claimed:
<-- snip -->
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
<-- snip -->
You were clearly saying that whom you call
Adrian Bunk wrote:
You claimed:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
-- snip --
You were clearly saying that whom you call they
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote:
Adrian Bunk wrote:
You claimed:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall [EMAIL PROTECTED] wrote:
For sure, a root user can get out of a chroot a million different
ways. Young Alan said as much at the beginning of this
conversation, and I have always agreed. I don't hope to secure Linux
within chroot, simply to
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
So the OpenBSD man page seems to be in the minority here. Any portable
code can not assume that CWD changes. And changing the Linux behaviour
now would be a rather big change which might break userspace. And yes,
there are
Theodore Tso wrote:
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
So the OpenBSD man page seems to be in the minority here. Any portable
code can not assume that CWD changes. And changing the Linux behaviour
now would be a rather big change which might break userspace.
Bill Davidsen wrote:
It seems there are (at least) two parts to this, one regarding
changing working directory which is clearly stated in the standards
and must work as it does, and the various issues regarding getting out
of the chroot after the cwd has entered that changed root. That second
On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
> <-- snip -->
>
> Look, when chroot was being designed, I think they intended that even root
> should be unable to get out. They went so far as to say that dot-dot
> wouldn't let you out; and it doesn't.
>
> <-- snip -->
>
>
On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote:
> Adrian Bunk wrote:
>> You are claiming "They went so far as to say that dot-dot wouldn't let you
>> out"?
>>
>
> I phrased it in a somewhat conversational way. The promise, which I've now
> quoted from multiple sources, is
Adrian Bunk wrote:
You are claiming "They went so far as to say that dot-dot wouldn't let
you out"?
I phrased it in a somewhat conversational way. The promise, which I've
now quoted from multiple sources, is expressed variously, including:
The dot-dot entry in the root directory is
On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote:
>...
> Look, when chroot was being designed, I think they intended that even root
> should be unable to get out. They went so far as to say that dot-dot
> wouldn't let you out; and it doesn't.
>...
You are claiming "They went so far
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Al Viro wrote:
> > Oh, for fsck sake... Folks, it's standard-required behaviour.
> > Ability to chroot() implies the ability to break out of it. Could
> > we please add that (along with reference to SuS) to l-k FAQ and
On Wed, 26 Sep 2007, David Newall wrote:
> Miloslav Semler pointed out that a root process can chdir("..") out of
> its chroot. Although this is documented in the man page, it conflicts
> with the essential function, which is to change the root directory of
> the process.
The root directory,
On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote:
> Al Viro wrote:
> >Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
> >to chroot() implies the ability to break out of it. Could we please
> >add that (along with reference to SuS) to l-k FAQ and be done with
Alan Cox wrote:
** Plonk **
Welcome to my killfile.
Well that's a relief.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
** Plonk **
Welcome to my killfile.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox wrote:
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
How bizarre. Last email you claimed to quote the standards (but you
never did.) Your becoming an embarrassment. You were rude, and
multiple times. Please just
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Alan,
Alan Cox wrote:
therefore it must be right. You present no reasoning to explain why the
behavior is correct; instead you use insults. I've exhausted my
tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Did you just tell a porky? Did
Once upon a time, Alan Cox <[EMAIL PROTECTED]> said:
>Well if citing standards documents at people is rudeness so be it.
I hate to get involved in this, but actually chroot() is no longer part
of SuS as of version 3.
For other Unix versions, both Tru64 (5.1B) and Solaris (9) chroot(2) man
pages
> therefore it must be right. You present no reasoning to explain why the
> behavior is correct; instead you use insults. I've exhausted my
> tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Alan
-
To unsubscribe from this list: send the line
Alan Cox wrote:
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you haven't)
My, my, you can be unpleasant when you try. There's no need for it. As
it happens I have years of UNIX experience on you. (Newbie!)
> I've made no error. The documentation says what it says, and what it
> doesn't say, other than for Linux, is that there is an unspecified way
> of breaking out.
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you
Alan Cox wrote:
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <[EMAIL PROTECTED]> wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS)
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Al Viro wrote:
> > Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
> > to chroot() implies the ability to break out of it. Could we please
> > add that (along with reference to SuS) to l-k FAQ
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
nonsense?
I'm pretty confident that it's only standard behavior
Al Viro <[EMAIL PROTECTED]> wrote:
> If you are within chroot jail and capable of chroot(), you can chdir to
> its root, then chroot() to subdirectory and you've got cwd outside of
> your new root. After that you can chdir all way out to original
> root.
Here is some code I wrote a while
Al Viro [EMAIL PROTECTED] wrote:
If you are within chroot jail and capable of chroot(), you can chdir to
its root, then chroot() to subdirectory and you've got cwd outside of
your new root. After that you can chdir all way out to original
root.
Here is some code I wrote a while back to
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
nonsense?
I'm pretty confident that it's only standard behavior
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall [EMAIL PROTECTED] wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done
Alan Cox wrote:
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall [EMAIL PROTECTED] wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to
I've made no error. The documentation says what it says, and what it
doesn't say, other than for Linux, is that there is an unspecified way
of breaking out.
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you
Alan Cox wrote:
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you haven't)
My, my, you can be unpleasant when you try. There's no need for it. As
it happens I have years of UNIX experience on you. (Newbie!)
therefore it must be right. You present no reasoning to explain why the
behavior is correct; instead you use insults. I've exhausted my
tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Alan
-
To unsubscribe from this list: send the line
Once upon a time, Alan Cox [EMAIL PROTECTED] said:
Well if citing standards documents at people is rudeness so be it.
I hate to get involved in this, but actually chroot() is no longer part
of SuS as of version 3.
For other Unix versions, both Tru64 (5.1B) and Solaris (9) chroot(2) man
pages
Alan,
Alan Cox wrote:
therefore it must be right. You present no reasoning to explain why the
behavior is correct; instead you use insults. I've exhausted my
tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Did you just tell a porky? Did
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Cox wrote:
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
How bizarre. Last email you claimed to quote the standards (but you
never did.) Your becoming an embarrassment. You were rude, and
multiple times. Please just
** Plonk **
Welcome to my killfile.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox wrote:
** Plonk **
Welcome to my killfile.
Well that's a relief.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
On Wed, 26 Sep 2007, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir(..) out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process.
The root directory, '/'
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall [EMAIL PROTECTED] wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour.
Ability to chroot() implies the ability to break out of it. Could
we please add that (along with reference to SuS) to l-k FAQ and be
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to
On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote:
...
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
...
You are claiming They went so far as to
Adrian Bunk wrote:
You are claiming They went so far as to say that dot-dot wouldn't let
you out?
I phrased it in a somewhat conversational way. The promise, which I've
now quoted from multiple sources, is expressed variously, including:
The dot-dot entry in the root directory is
On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote:
Adrian Bunk wrote:
You are claiming They went so far as to say that dot-dot wouldn't let you
out?
I phrased it in a somewhat conversational way. The promise, which I've now
quoted from multiple sources, is expressed
On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
-- snip --
You were
On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote:
> Alan Cox wrote:
> >On Fri, 21 Sep 2007 13:39:34 -0400
> >Phillip Susi <[EMAIL PROTECTED]> wrote:
> >
> >>David Newall wrote:
> >>>* In particular, the superuser can escape from a =91chroot jail=92 by d=
> >>>oing=20
> >>>=91mkdir foo;
Alan Cox wrote:
On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi <[EMAIL PROTECTED]> wrote:
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
No, he can not.
The superuser can escape that way - its
On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
> Miloslav Semler pointed out that a root process can chdir("..") out of its
> chroot. Although this is documented in the man page, it conflicts with the
> essential function, which is to change the root directory of the process.
> Marek's loading dynamic libraries, it seems clear that the prime purpose
> of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that. I think you are confusing
containers and chroot. They are quite different things. A root user can
get
On Sep 26 2007 00:40, David Newall wrote:
>
> Miloslav Semler pointed out that a root process can chdir("..") out of its
> chroot. Although this is documented in the man page, it conflicts with the
> essential function, which is to change the root directory of the process. In
> addition to any
Miloslav Semler pointed out that a root process can chdir("..") out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process. In addition to any creative uses, for example Philipp
Marek's
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on
a chroot bug), but it'd still be unportable.
It can.
Quoting David Newall ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> Quoting David Newall ([EMAIL PROTECTED]):
>>
>>> It might be tidy if pivot_root could be used (instead of a hack based on
>>> a chroot bug), but it'd still be unportable.
>>>
>>
>> It can.
>>
>> Please re-read my
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on a
chroot bug), but it'd still be unportable.
It can.
Please re-read my previous msg.
I read it. Currently pivot_root can't be used to affect a
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on a
chroot bug), but it'd still be unportable.
It can.
Please re-read my previous msg.
I read it. Currently pivot_root can't be used to affect a
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on
a chroot bug), but it'd still be unportable.
It can.
Please re-read my previous msg.
I read it.
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on
a chroot bug), but it'd still be unportable.
It can.
Miloslav Semler pointed out that a root process can chdir(..) out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process. In addition to any creative uses, for example Philipp
Marek's loading
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir(..) out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to change the root directory of the process. In
addition to any
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that. I think you are confusing
containers and chroot. They are quite different things. A root user can
get
On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir(..) out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to change the root directory of the process.
In
Alan Cox wrote:
On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi [EMAIL PROTECTED] wrote:
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
No, he can not.
The superuser can escape that way - its expected
On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote:
Alan Cox wrote:
On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi [EMAIL PROTECTED] wrote:
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
Quoting David Newall ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root. Just clone your mounts
>> namespace first.
>>
>> unshare(CLONE_NEWNS);
>> chdir(new_dir);
>> pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles
Quoting David Newall ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root. Just clone your mounts
>> namespace first.
>>
>> unshare(CLONE_NEWNS);
>> chdir(new_dir);
>> pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts, this is really the
only way to go
Quoting David Newall ([EMAIL PROTECTED]):
> Bill Davidsen wrote:
>> there is no question that pivot_root is intended to have breadth for more
>> than one process.
>
> I think it's clear from the man page that the original idea was to be able
> to pivot_root for individual processes. The reason
Quoting David Newall ([EMAIL PROTECTED]):
Bill Davidsen wrote:
there is no question that pivot_root is intended to have breadth for more
than one process.
I think it's clear from the man page that the original idea was to be able
to pivot_root for individual processes. The reason it
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts, this is really the
only way to go
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts,
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts,
On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi <[EMAIL PROTECTED]> wrote:
> David Newall wrote:
> > * In particular, the superuser can escape from a =91chroot jail=92 by d=
> > oing=20
> > =91mkdir foo; chroot foo; cd ..=92.
>
> No, he can not.
The superuser can escape that way - its expected
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
No, he can not.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Bill Davidsen wrote:
there is no question that pivot_root is intended to have breadth for
more than one process.
I think it's clear from the man page that the original idea was to be
able to pivot_root for individual processes. The reason it doesn't do
that, the reason it affects all
Bill Davidsen wrote:
there is no question that pivot_root is intended to have breadth for
more than one process.
I think it's clear from the man page that the original idea was to be
able to pivot_root for individual processes. The reason it doesn't do
that, the reason it affects all
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
No, he can not.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi [EMAIL PROTECTED] wrote:
David Newall wrote:
* In particular, the superuser can escape from a =91chroot jail=92 by d=
oing=20
=91mkdir foo; chroot foo; cd ..=92.
No, he can not.
The superuser can escape that way - its expected and fine
David Newall wrote:
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being "intentionally
vague". However the goal seems clear:
"pivot_root() moves the root file system of the current process to
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being "intentionally
vague". However the goal seems clear:
"pivot_root() moves the root file system of the current process to
the directory
On Thursday 20 September 2007 David Newall wrote:
> Philipp Marek wrote:
> > - User starts a small wrapper,
> > - that opens "/",
> > - chroot()s into a directory and starts fsvs.
> > - fsvs gets its libraries loaded
> > - and chroot()s back to the original system.
>
> Isn't that what pivot_root
Philipp Marek wrote:
- User starts a small wrapper,
- that opens "/",
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.
Isn't that what pivot_root was meant for?
-
To unsubscribe from this list: send the line
Philipp Marek napsal(a):
Please, everybody,
don't change that.
I'm currently using that *feature* (yes, I see it as that) in my
fsvs-chrooter-utility (see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
for easier usage of fsvs on older
Please, everybody,
don't change that.
I'm currently using that *feature* (yes, I see it as that) in my
fsvs-chrooter-utility (see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
for easier usage of fsvs on older systems.
- User starts a
David Newall <[EMAIL PROTECTED]> wrote:
>> Normal users cannot use chroot() themselves so they can't use chroot to
>> get back out
>
> I think Bill is right, that this is to fix a method that non-root
> processes can use to escape their chroot. The exploit, which is
> documented in chroot(2)*,
David Newall [EMAIL PROTECTED] wrote:
Normal users cannot use chroot() themselves so they can't use chroot to
get back out
I think Bill is right, that this is to fix a method that non-root
processes can use to escape their chroot. The exploit, which is
documented in chroot(2)*, is to
Please, everybody,
don't change that.
I'm currently using that *feature* (yes, I see it as that) in my
fsvs-chrooter-utility (see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
for easier usage of fsvs on older systems.
- User starts a
Philipp Marek napsal(a):
Please, everybody,
don't change that.
I'm currently using that *feature* (yes, I see it as that) in my
fsvs-chrooter-utility (see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
for easier usage of fsvs on older
Philipp Marek wrote:
- User starts a small wrapper,
- that opens /,
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.
Isn't that what pivot_root was meant for?
-
To unsubscribe from this list: send the line unsubscribe
On Thursday 20 September 2007 David Newall wrote:
Philipp Marek wrote:
- User starts a small wrapper,
- that opens /,
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.
Isn't that what pivot_root was meant for?
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being intentionally
vague. However the goal seems clear:
pivot_root() moves the root file system of the current process to
the directory put_old
David Newall wrote:
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being intentionally
vague. However the goal seems clear:
pivot_root() moves the root file system of the current process to
1 - 100 of 110 matches
Mail list logo
