Re: [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

2007-10-26 Thread Miklos Szeredi
On Fri, 2007-10-26 at 13:30 +0200, Miklos Szeredi wrote: So I think the correct solution (which was suggested by Trond and others) is to define an f_op-fsetattr() method, which interested filesystems can define. And here's the patch, which applies on top of the f_op-fgetattr() patch

Re: [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

2007-10-26 Thread Miklos Szeredi
by Trond and others) is to define an f_op-fsetattr() method, which interested filesystems can define. Miklos Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED] Signed-off-by: John Johansen [EMAIL PROTECTED] Cc: Miklos Szeredi [EMAIL PROTECTED] --- fs/nfsd/vfs.c | 12 +++- fs

Re: [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

2007-10-26 Thread Miklos Szeredi
On Fri, 2007-10-26 at 22:24 +0200, Andreas Gruenbacher wrote: On Friday 26 October 2007 13:30, Miklos Szeredi wrote: There's a slight problem (other than HCH not liking it) with this approach of passing the open file in iattr: for special files, the struct file pointer makes no sense

Re: [patch] unprivileged mounts update

2007-04-26 Thread Miklos Szeredi
Quoting Miklos Szeredi ([EMAIL PROTECTED]): Right, I figure if the normal action is to always do mnt-user = current-fsuid, then for the special case we pass a uid in someplace. Of course... do we not have a place to do that? Would it be a no-no to use 'data' for a non-fs

Re: [patch] unprivileged mounts update

2007-04-25 Thread Miklos Szeredi
Right, I figure if the normal action is to always do mnt-user = current-fsuid, then for the special case we pass a uid in someplace. Of course... do we not have a place to do that? Would it be a no-no to use 'data' for a non-fs-specific arg? I guess it would be OK for bind, but not for