About this list Date view Thread view Subject view Author view Attachment view

From: Chris Wright (chris_at_wirex.com)
Date: Wed 14 Nov 2001 - 19:57:40 GMT

* Sam Vilain (sam_at_vilain.net) wrote:
> ping calls:
> I don't know how you could wrap a capability around that, without still
> allowing arbitrary ICMP traffic out.

i agree, CAP_NET_RAW gives this away, carte blanche. but wouldn't this
only be useful for setuid root programs, and the vserver's root user.
this may not be too bad?? i agree that it would be useful.

> Damnit, we need add-capability-on-execute binaries, and there just aren't
> enough bits in ext2_inode.i_flags

hehe, have no fear, extended attributes are on the way RSN ;-)

> But wait! I see ext2_inode.linux1.l_i_reserved1, which is __u32 (the same
> as kernel_cap_t). This looks OK, except that there are only 2 capability
> bits unallocated in kernel_cap_t. I see that someone has had the
> foresight to use a 64-bit type for the user-space structure, and there's
> always ext2_inode.linux2.l_i_reserved2 (32 bits) or
> ext2_inode.linux2.i_pad, (16 bits) to overflow new capabilities to on
> disk.

boy, i'd really resist any temtation to muck in the ext2 layer. i know
this is already done for the immutable changes, but anytime you move to
the filesystem layer you've lost the abstraction and coupled your
solution to a particular filesystem ;-(

> On a side note, I think we should set up a wiki for this project's
> documentation.

good idea ;-)


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:38 GMT by hypermail 2.1.3