lkml.org 
[lkml]   [1999]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ext3 to include capabilities?
On Wed, 7 Apr 1999, Albert D. Cahalan wrote:

> >>> It's a no-lose situation until you start using the new features to add
> >>> privileges which weren't there in the first place.

> >> Are you suggesting that the whole system should break when you reboot to
> >> an old kernel?
> >
> > Yep.
>
> That sucks. You might as well just crash in that case.

panic("Capabilities in filesystem - tell Albert\n");

> >> A lot of people are going to want to remove the suid bit from existing
> >> executables and add capabilities. If that then breaks when they reboot
> >> to an old kernel, then we've done something blatantly wrong. Using the
> >> suid bit as a marker to show the presence of a 'capability header' seems
> >> like an ideal solution, because it provides backwards compatibility
> >> without any loss of security in relation to the _existing_ situation.
> >
> > s/the suid bit/an ext2 inode flag/ and I'll be convinced.
>
> No, that won't work over NFS. It won't work with tar, cpio...

Nor do the other ext2 extended attributes or ACLs, neither of which can be
done sensibly in userspace.

> >> New capability-holding utilities that were never suid and should never
> >> be suid can just include that one-liner I gave above.
> >
> > Cruft. Look at the subject - we're not talking about existing systems.
> > This is a new and probably incompatible filesystem.
>
> The whole ext3 idea is stupid. Why bother with yet another UFS-like
> filesystem? We have one, it works well, it is extendible enough, and
> it will last us until we get something like XFS or AdvFs. (Reiserfs)

Because we need a journalled filesystem, and that can't really be done
without breaking compatibility. It's not a whole new filesystem - it's
just some badly needed extensions to an old one. It's doesn't require a
complete redesign and reimplementation, but it does require a different
type

reiserfs is looking good, but people want a journalled filesystem soon and
Stephen reckons that he'll be ready for an initial code release within a
month or two. reiserfs isn't yet officially released (although I note
that ext2 is still nominall at version 0.5b :) and certainly hasn't has
the years of batterning that e2fs has.

> With hindsight, I could lay out the inode better. Who cares though?
> The existing one works well enough.

So don't use the "ext3". Stick with ext2 and do the capability stuff in
ELF headers or completely in userspace. It's not too hard - in ping:

dropcap(CAP_MASK & ~CAP_RAWSOCK);
seteuid(getuid());

or similar. Personally, I will

> > Personally, I hope that ext3 won't bother with providing backwards
> > compatibility to old kernels, but rather will clear out old backwards
> > compatibility code, add the exciting new stuff (ACLs, capabilities) and
> > fix some things (bigger [ug]id_t, dev_t, (off_t?)). The rest is missing
> > the point, IMHO.
>
> There is no need for ext3.

No. The above are not sufficient reason to create a new, incomplatible
filesystem. There are other good reasons, though, and it would seem to me
a missed opportunity not to throw in the other goodies while you're at it.

> Larger data types are trivial, since the space is already reserved.

We seem to have 3*32 bits spare. That's enough to extend dev_t, uid_t and
gid_t, but not much more.

> Ext2 isn't a stupid filesystem in need of vfat-like hacks. Even the
> more difficult ACLs can be supported, although userspace will often
> screw up with them.

ext2 has reserved space for ACLs already.

> Capabilities could be supported in ext2, but they would be a waste of
> inode space and source of major app & protocol incompatibility. We can
> do just fine with capability information embedded in the executable.
>
> Compatibility is critical.
>
> I'm still waiting for a filesystem-based proposal that works with NFS.

I'm still waiting for a decent networked filesystem based around a
reasonably extensible protocol.

Matthew.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.141 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site