Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: Re: Re: Re: Re: Re: exiting a chroot environment

by sauoq (Abbot)
on Jul 09, 2003 at 01:55 UTC ( #272537=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: Re: Re: exiting a chroot environment
in thread exiting a chroot environment

But if, after chroot()'ing, "." acts differently for root than it does for every other user, then isn't root being treated as a special case? Mustn't there be a check against the uid somewhere? That's the special case I'm talking about.

It seems to me that you are saying, on Linux, in a chroot() environment, '.' is a special case for every user except root... I suppose you might look at it that way, but it seems a bit backward and I still don't understand where the reduction in code complexity comes from.

Regarding '..', I don't understand why that would be any more of a special case than it usually is (that is '/..' being equivalent to '/').

I'm sure I'll have to start digging through source code before I understand your point.

"My two cents aren't worth a dime.";
  • Comment on Re: Re: Re: Re: Re: Re: exiting a chroot environment

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: exiting a chroot environment
by MarkM (Curate) on Jul 09, 2003 at 01:59 UTC

    I believe the conflict in our understanding is in each of our understanding on where the /.. = /. = / magic is implemented. My understanding of the file system structures tells me that /.. = /. = / is implemented at mkfs time, not at run time. The '..' and '.' entries in '/' both refer to the same inode as '/' refers to. There is no special magic in the kernel.

    It is possible that I am incorrect, however, I suggest to you that my understanding is the only understanding that explains why Linux allows users to escape a chroot() jail by referring to '.' and './..'.


    I think we are both wrong. I can't seem to escape the Linux chroot() jail in any of the ways listed above unless '.' was already outside the chroot() jail, which is the exploit that the man page refers to.

      explains why Linux allows users to escape a chroot() jail

      Ah, but Linux, AFAIK, doesn't allow just any user to escape the chroot() environment. It only allows the super-user to escape it.

      I think we might be referring to two different special cases.

      As for when /.. = /. = / is implemented, I wouldn't think it would happen during mkfs because mkfs would have no way of knowing whether the filesystem in question would be used as the root fs or not. (Might there be something going on when the root fs is mounted?) My understanding of this stuff is admittedly weak; I'd be happy to receive some enlightenment.

      "My two cents aren't worth a dime.";

        The root file system is the only file system that doesn't need /. and /.. to be special.

        The special case is when a file system is mounted as a non-root filesystem, as then /mount/point/.. needs to appear to refer to the same inode as /mount does. The same is true of chroot(). The Linux code seems to jump through quite a few hoops (with functions names like 'graft_tree()') to deal with mounts...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://272537]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2018-06-24 09:46 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.