Ah, I understand now. This should not be a bitmap, this should be a function
call, and the FS should be free to represent the compression of these
capabilities however it wants to.
Agree?
Hans
Chris Evans 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.
>
> Cheers
> Chris
-- Get Linux (http://www.kernel.org) plus ReiserFS (http://devlinux.org/namesys). If you sell an OS or internet appliance, buy a port of ReiserFS! If you need customizations and industrial grade support, we sell them.- 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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:21 EST