>>> It's a no-lose situation until you start using the new features to add
>>> privileges which weren't there in the first place.
>>
>> That's not the common case, though - the first things that get converted
>> to use capabilities will surely be the existing suid stuff, won't they?
>>
>> 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.
>> 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...
>> 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)
With hindsight, I could lay out the inode better. Who cares though?
The existing one works well enough.
The name itself is bad. When we had both "ext" and "ext2", people
would try to use "ext" to mount "ext2" partitions. It didn't work
of course.
> 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.
Larger data types are trivial, since the space is already reserved.
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.
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.
-
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/