public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Emmanuel Colbus <ecolbus@manux.info>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][1/11][MANUX] Kernel compatibility : ext2
Date: Tue, 15 Apr 2014 18:27:47 -0400	[thread overview]
Message-ID: <20140415222747.GN4456@thunk.org> (raw)
In-Reply-To: <534DA90C.7000507@manux.info>

On Tue, Apr 15, 2014 at 11:47:56PM +0200, Emmanuel Colbus wrote:
> 
> By the way, just asking : if this is an NFS version field, is the
> content of this field significant when no NFS has ever been used to
> export this filesystem?

No.  But ext4 may end up changing the value of the i_version field,
from one non-zero value to some other non-zero value field.

> My OS heavily uses chroots for security purposes (these are not true
> Linux-like chroots, but this isn't relevant). One of the issues of
> chroots is that one can escape from them, by simply having one process
> open a fd towards a directory, another one move the directory inside a
> second directory located outside of the first process' chroot, and then
> have the first process perform enough fchdir(fd, ".."); or something of
> the like.

If there a process which is out side of the chroot which is
cooperating to help someone breakout of the chroot, that means you
have a bad actor who is outside of the chroot already.  So why bother
worrying about this case?

The more interesting way to break out of a crhoot, which doesn't
require a 2nd process to help you escape, is to chroot while inside a
chroot:

	www.bpfh.net/simes/computing/chroot-break.html

And if you care about this problem, Linux has a much more general
solution using mount namespaces.  FreeBSD has its own a solution
involving restrictions on chroot:

www.freebsd.org/cgi/man.cgi?query=chroot&sektion=2&apropos=0&manpath=FreeBSD+4.0-RELEASE


> Alright, then. Here's what I plan to do :
> - In the short term, I'm going to continue with what I'm currently doing
> with ext2 filesystems, but warn my users against mounting such a
> filesystem in read-write mode if they're also mounting it with ext4 and
> exporting it with NFS;

The main issue is what is the goal of your creating your own OS?  If
it's for your own edication, that's great.  Have fun, it's a great way
to learn.  If you're going to actually try to market this to other
users, you should make sure you understand how much effort it takes to
support a new file system, let alone a new operating system.  Hurd
tried to go down a path somewhat like yours, and it's taken them
years, and the result from a performance point of view is still pretty
bad.  Keep in mind that ext2 has many limitations, including crash
recovery, performance, and scalability.

If you are planning on creating a production quality OS using ext2 as
its base, it does seem a little naive, though.

Regards,

						- Ted

  reply	other threads:[~2014-04-15 22:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 13:42 [RFC][1/11][MANUX] Kernel compatibility : ext2 Emmanuel Colbus
2014-04-15 20:04 ` Theodore Ts'o
2014-04-15 21:47   ` Emmanuel Colbus
2014-04-15 22:27     ` Theodore Ts'o [this message]
2014-04-16  2:12       ` Emmanuel Colbus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140415222747.GN4456@thunk.org \
    --to=tytso@mit.edu \
    --cc=ecolbus@manux.info \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox