On Sunday 10 November 2002 02:32, Theodore Ts'o wrote:
> On Sun, Nov 10, 2002 at 01:35:26AM +0100, Andreas Gruenbacher wrote:
> > If so, an unprivileged process that accesses a file has no direct
> > access to the HSM meta data. The in-kernel code that implements HSM
> > needs access to the HSM meta data to decide whether the file in
> > question is online or offline, etc. Currently file systems can't
> > tell if an extended attribute operation originated from the current
> > user space process, or from in-kernel code in support of the current
> > user space process. Would passing credentials down the xattr
> > operations make sense?
>
> Well, we don't need to pass a full set of credentials down; the only
> thing the xattr functions needs to know is whether should be
> considered "privileged" (i.e., for the benefit of in-kernel code or
> not). So all we need to do is to pass a single bit down to the xattr
> functions.
>
> For i_op->setxattr, we already have a flags argument, so adding a new
> flag would be pretty trivial. Unfortunately, we would need to add a
> new argument to i_op->getxattr, i_op->listxattr, and
> i_op->removexattr.... and it's after feature freeze.
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).
int (*setxattr) (struct dentry *, const char *, void *, size_t, int,
struct task_struct *);
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t,
struct task_struct *);
ssize_t (*listxattr) (struct dentry *, char *, size_t,
struct task_struct *);
int (*removexattr) (struct dentry *, const char *,
struct task_struct *);
> So while this is a relatively trivial change, I'd just as soon wait
> until after Linus accepts some patch which completely replaces the
> algorithms used by the core VM or Block I/O layers before I'd try to
> advocate making a change to the VFS at this point. Let someone else
> destroy the feature freeze first. :-/
:-)
--Andreas.
|