In <Pine.LNX.email@example.com> Chris Evans (firstname.lastname@example.org) wrote:
> On Fri, 11 Feb 2000, Matthew Kirkwood wrote:
>> Ah, I wasn't aware that was possible. I had assumed that your
>> stat_data was rather fixed in size.
>> That being the case, I would like:
>> __u32 flags; /* ext2 compatible file flags */
>> __u32 cap_allowed; /* allowed capabilities */
>> __u32 cap_forced; /* forced capabilities */
>> If you can do that without breaking the disk format, then it
>> can wait for 2.5, otherwise I think it would make sense for
>> them to appear in 2.3 (assuming that the format has already
>> changed for the 2.3 port?).
> See another mail I just sent. Looking at the future picture, we are using
> 28/32 capabilties. The rate at which we are finding "holes" in the
> capability list is admittedly small. However, I expect this to accelerate
> as people are starting to use capabilities to de-priv programs.
> I would be happier with 64 bit (or greater) capability fields in any
> filesystem structures; it has the potential to save a lot of grief in the
Huh.I can be wrong but why, oh WHY everyone is trying to add low limits in
design just to try to break then later ? 32, 64 or 128 WILL NOT be enough in
long run. I can understood why capabilities in kernel are 32bit word:
1. they are checked quite often and so it should be doable FAST and
2. they can be extended in future without big fuzz (it's internal kernel
structures so only few system calls should be changed)
On other hand once something added to filesystem, it's added to FILESYSTEM.
Read "set in stone". It's VERY hard to fix something there. And starting of
program is NOT time-critical operation. Even if you put capabilities in
separate file and store inode number of that file in inode of capability-enabled
file this will not slow process starting much (even if IMO it's overkill).
So 32bit is not way to go and even 64 is not enough. IMHO anyway.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:22 EST