lkml.org 
[lkml]   [2000]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.087 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site