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 ar
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, simpl
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;
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 "th
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
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 expres
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 interp
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 a
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 attempt
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 tha
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 http://ww
** 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 drop
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,
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
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 "unsubsc
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!)
You
> 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 hav
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) t
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
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 for
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
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 expecte
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 o
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 c
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
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.
Plea
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 previou
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 s
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 wi
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 wi
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 about
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
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 a
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 a
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 proces
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 put_ol
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 wa
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
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 sys
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 smal
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
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 chdir("..") your way out. Who'd have
thought
> I thought this was to prevent breaking out of chroot as a normal user.
> ie. chroot /var/myjail /bin/su - guest
> or similar.
Normal users cannot use chroot() themselves so they can't use chroot to
get back out
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Alan Cox wrote:
On Wed, 19 Sep 2007 09:19:50 +0200
majkls <[EMAIL PROTECTED]> wrote:
Hello,
here is an fix to an exploit (obtained somewhere in internet). This
exploit can workaround chroot with CAP_SYS_CHROOT. It is also possible
(with sufficient filedescriptor (if there is na directory fd o
On Wed, 19 Sep 2007 09:19:50 +0200
majkls <[EMAIL PROTECTED]> wrote:
> Hello,
> here is an fix to an exploit (obtained somewhere in internet). This
> exploit can workaround chroot with CAP_SYS_CHROOT. It is also possible
> (with sufficient filedescriptor (if there is na directory fd opened in
>
Hello,
here is an fix to an exploit (obtained somewhere in internet). This
exploit can workaround chroot with CAP_SYS_CHROOT. It is also possible
(with sufficient filedescriptor (if there is na directory fd opened in
root) workaround chroot with sys_fchdir. This patch fixes it.
Miloslav Semle
55 matches
Mail list logo
