On Monday 11 November 2002 22:05, Theodore Ts'o wrote:
> 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.
Yes, I was thinking of passing in NULL in the privileged case.
> 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.
I wasn't thinking of different permissions for different attributes, but of a
way do decouple the running process from the credentials seen in the file
system. The only cases at the moment are kernel context vs. process context,
but other cases might come up in the future (NFS?).
> 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.
I agree to that.
--Andreas.
|