On Wed, Jul 06, 2005 at 02:56:52PM +1000, Nathan Scott wrote:
> Hi Nicholas,
>
> On Sat, Jul 02, 2005 at 10:41:08PM +0100, Nicholas Hans Simmonds wrote:
> > This is a simple attempt at providing capability support through extended
> > attributes.
> > ...
> > +#define XATTR_CAP_SET XATTR_SECURITY_PREFIX "cap_set"
> > ...
> > + ret = bprm_getxattr(bprm_dentry,XATTR_CAP_SET,&caps,sizeof(caps));
> > + if(ret == sizeof(caps)) {
> > + if(caps.version == _LINUX_CAPABILITY_VERSION) {
> > + cap_t(bprm->cap_effective) &= caps.mask_effective;
> > ...
>
> Since this is being stored on-disk, you may want to consider
> endianness issues. I guess for binaries this isn't really a
> problem (since they're unlikely to be run on other platforms),
> though perhaps it is for shell scripts and the like. Storing
> values in native endianness poses problems for backup/restore
> programs, NFS, etc.
>
> IIRC, the other LSM security attribute values are stored as
> ASCII strings on-disk to avoid this sort of issue.
>
> cheers.
>
Sorry, my earlier reply seems to have gotten lost somewhere. I've been
pondering this issue for some time and am still not sure what's the best
answer. I've attached a small patch which handles this by detecting byte
swapping of the version code. I'm not convinced it's necessary but
shouldn't hurt.
diff --git a/security/commoncap.c b/security/commoncap.c
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -153,6 +153,15 @@ int cap_bprm_set_security (struct linux_
down(&bprm_dentry->d_inode->i_sem);
ret = bprm_getxattr(bprm_dentry,XATTR_CAP_SET,&caps,sizeof(caps));
if(ret == sizeof(caps)) {
+ if(caps.version = swab32(_LINUX_CAPABILITY_VERSION)) {
+ swab32s(&caps.version);
+ swab32s(&caps.effective);
+ swab32s(&caps.mask_effective);
+ swab32s(&caps.permitted);
+ swab32s(&caps.mask_permitted);
+ swab32s(&caps.inheritable);
+ swab32s(&caps.mask_inheritable);
+ }
if(caps.version == _LINUX_CAPABILITY_VERSION) {
cap_t(bprm->cap_effective) &= caps.mask_effective;
cap_t(bprm->cap_effective) |= caps.effective;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |