On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote:
> I think adding a (struct task_struct *) parameter to the xattr inode
> operations is a better idea --- I don't know how likely it is that
> credentials will be passed around in a future kernel, but if it's
> likely then the xattr inode operations would move in the right
> direction, instead of introducing weird flag(s).
But that won't help the problem which was originally stated. In an
HSM setup, there will be a kernel module that will be executing on
behalf of untrusted user space code, but it will want set a trusted
user attribute. So being able to pass in a pointer to another task
isn't going to be useful; there isn't another task's credentials that
should be used. Instead, though, what you need is a way to tell the
xattr code that "this is a privileged operation". And that requires
but a single bit.
Asking the HSM module to fake up a task structure just so it can
create a "credential" that has CAP_SYS_ADMIN set is simply madness.
The other thing to consider here is that I really don't want to start
us down the path where individual user attributes are owned by some
user or group other than the owner or group owner of the base file.
When you start talking about "credentials being passed around", as
opposed to simply a single bit which says, "this is official kernel
business", you're scaring me.
We **DON'T** want to have user and group ownership of xattrs. Next
thing you know, people will start wanting ACL's on xattrs. And then
it will all go downhill from there. ACL's on ACL's? ACL's on ACL's
on ACL's? ACL's on ACL's on ACL's on ACL's? Please, God, No. We
have to draw a line and say no the madness somewhere, and I think it
should be done sooner rather than later.
- Ted
|