On Fri, 2002-11-15 at 11:07, Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, Nov 11, 2002 at 04:05:24PM -0500, 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).
>
> > 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.
>
> Perhaps, but do we need it?
>
> I'd have thought that the likely model for an HSM system is that the
> requesting user process would find the inode marked "not-in-core", and
> would pass the "please make this inode resident" request out to a
> separate process for completion. Only that external process would
> require access to the HSM metadata, so it's not immediately obvious
> why the initial caller process absolutely has to have access to the
> HSM metadata.
That's the way our HSM works ;-).
The inode and any thing like ACLs etc is always on disk, and permission
to look at the contents can be determined without the contents being
present. Once past this point, the data is discovered to be offline
and the HSM daemons are responsible for bringing it back on line, they
are the only ones who need to manipulate HSM related metadata. The
user's thread does need to be able to work out that it is offline.
Steve
|