On Feb 15, 2008, at 10:18 AM, Marc REYNES wrote:

Thanks Richard for your reply and your great work on QuickFacts!

I contribute what I can...

Anyway, I would mitigate your answer on two points :
- is your reply also correct if dsmc is setuid-ed for a non
superuser ?

Not to be evasive, but I don't see that as a valid scenario, in that
you would run afoul of the TSM conventions for local storage of the
client password, for PASSWORDAccess Generate, as needed for
scheduling.  I'd advise not going there.  And, arbitrarily changing
the design intention of an executable to make it setuid can lead you
into inadvertent security issues, which are best avoided by using the
executable as the provider intends and documents.

- For backup, solely an authorized user or a root user can backup
files while keeping ownership of the original file. It differs
effectively from Archive.
As quoted in the sec. guide :
"""The reason why a non-authorized user can archive files that the
non-authorized user does
not own, although this user cannot back them up, is that otherwise
the version-based policy of
backed up objects allows the user to quickly saved object versions
by running repeated
backup operations. That way, a user can force the expiration of
historical data, which belongs
to other users, that was not supposed to be removed from storage at
that time."""

Fine with me.  :-)

   Richard