Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 12 Feb 2000 15:34:20 +0300 (MSK) | Subject | Re: Capabilities |
| |
In <Pine.LNX.4.21.0002111309540.8492-100000@ferret.lmh.ox.ac.uk> Chris Evans (chris@ferret.lmh.ox.ac.uk) 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 > future.
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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |