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.025 / U:1.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site