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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.