On 08/28/09 07:24, Dean Roehrich wrote:
> On Fri, Aug 28, 2009 at 01:42:39AM -0700, Alan M Wright wrote:
>> On 08/27/09 13:17, Dean Roehrich wrote:
>>> On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote:
>>>> On 08/26/09 14:33, Dean Roehrich wrote:
>>>>> On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote:
>>>>>>  The offline attribute (XAT_OFFLINE) will be added to the read-
>>>>>>  write system attributes view defined in PSARC/2007/315 and will be
>>>>>>  generally available to file systems and applications to indicate
>>>>>>  the offline/online status of objects: boolean value of true
>>>>>>  indicates the object is offline.  In order to set or clear the
>>>>>>  offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES
>>>>>>  permission or the PRIV_FILE_OWNER privilege.  In the kernel, it
>>>>>>  will be accessible via VOP_GETATTR() and VOP_SETATTR().  In user
>>>>>>  space, it will be accessible via chmod(1), ls(1) and fgetattr(3C).
>>>>>>  No changes are required to the VOP or fgetattr(3C) function
>>>>>>  prototypes.
>>>>> An HSM does not want the file's owner to twiddle this status.  That 
>>>>> status
>>>>> should be controlled by the HSM.
>>>> The file system can return EACCES or EPERM if it doesn't want
>>>> the attribute changed via fsetattr(3C).
>>>>
>>>> I didn't want to preclude user space applications from being
>>>> able to manipulate this attribute on regular (non-HSM) file
>>>> systems.  As I mentioned, a virus scanner could be configured
>>>> to mark the file as offline while it is performing a scan-on-
>>>> open.
>>> In that case, how would the virus scanner and the HSM interoperate on the 
>>> same
>>> filesystem?
>> I think that's outside the scope of this case - that would be a
>> design consideration for those components.  And there's already
>> a potential interaction problem between virus scanning and HSM:
>> virus scanners may keep pulling files onto primary storage if
>> poorly configured.
>>
>> Perhaps a well-designed virus scanner would recognize when the
>> offline bit is already set and not attempt to scan files during
>> background/scheduled scanning, and perhaps it's a bad idea for
>> a virus scanner to manipulate the offline bit.  Hopefully, these
>> are application specific design problems that we have to solve
>> here.
>>
>>> Given your use-case, how would an HSM know when it can trust or use this 
>>> bit?
>> If an HSM is managing the offline bit it can simply return EPERM
>> if anything external to the HSM tries to change the state of that
>> attribute.  Nothing here requires that a file system or HSM allow
>> the offline attribute to be changed outside of its control.
> 
> Customers will write applications (maybe a file browser) which query this bit,
> and they'll file bugs against the HSM products for not setting it.

And perhaps that's appropriate because this case is an action
item from PSARC/2009/381 to introduce this attribute.

> The HSM
> products will then be in a bind because they know they can't use it as
> specified (at a minimum, they would have to modify fsetattr to no longer allow
> the setting of that bit, which would break some other customer's home-grown
> application...and so it goes).

There is absolutely no need to modify fsetattr() in this way, and
it would be wrong to apply or enforce policy in fsetattr().
fsetattr() is just a conduit.  As I said previously, the HSM or
file system can return EPERM.

> So here's how this case _could_ have been presented, given that it's supposed
> to displace PSARC/2009/381:

This case is not displacing PSARC/2009/381.

>  You introduce XAT_OFFLINE, which is owned by the
> HSM.  The virus scanner must honor this bit and avoid scanning offline files
> (there, now your virus scanner won't screw up the HSM resource management
> policy).

I think you're distracted by this hypothetical HSM/virus scanning
interaction but it's not relevant here.  An HSM or file system
can easily reject attempts to manipulate the offline attribute.
This is a non-issue.

Alan


Reply via email to