Messages in this thread | | | Date | Wed, 7 Apr 1999 12:27:06 +0100 (GMT) | From | Matthew Kirkwood <> | Subject | Re: 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/
| |