"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> I'd envision it as needing a new priv in addition to PRIV_FILE_OWNER,
> so that in the normal case, even with the new priv, one could only do it
> to one's own files.
>
> That leaves it up to a site: they can set up RBAC to allow only certain
> programs the ability to read files without updating their atime, or they
> can set up nothing (leaving only root able to do this), or they can grant
> the priv to individual users (and by extension to all users, if they wish).
>
> And by silently ignoring O_NOATIME rather than returning an error if it is
> used in the absence of the new privilege, compatibility with Linux's use
> is retained (since they effectively leave it up to the filesystem, and
> acknowledge
> that some filesystems like NFS won't be able to do anything with it). OTOH,
> the Linux open(2) man page says
>
> > EPERM The O_NOATIME flag was specified, but the effective user ID
> > of
> > the caller did not match the owner of the file and the
> > caller
> > was not privileged (CAP_FOWNER).
>
> so I suppose not being owner or holding PRIV_FILE_OWNER (in addition to the
> proposed new privilege) when using O_NOATIME should also error with EPERM.
>
> In other words, I'd want to lean a bit further than they do toward letting
> sites
> set policy, while still having otherwise similar enough function and
> semantics to
> make portability between the two a non-issue for this.
I could live with allowing a holder of PRIV_FILE_OWNER that is not the owner of
the file to keep atime.
I am not sure wether a file owner should be allowed to keep the old atime on
his files. Maybe this is the first thing we should discuss in order to find how
we like to implement the rest on Solaris.
We need pros and cons for allowing a file owner to keep atime on his files
and after collecting them, we should discuss them.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
