> >>> 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/