> > 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.
I think I gave raw material to construct at least one each already: pro: not only backups, but bulk file indexers, and perhaps similar as yet unidentified services, might have legitimate use for keeping atime unaltered while reading the files, both for performance, and because their accessing of all files e.g. under a user's home directory actually _loses_ useful information (what good does it do to know that all the files one of these utilities read were read within a few minutes of one another, compared with the utility of knowing the last times the user more explicitly accessed some of their files?). And one view of least privilege says that a user ought to be able to back up or index their own files, without needing a program that was setuid root or granted PRIV_FILE_OWNER to do it. So there would be some benefit in allowing a program run with no _existing_ additional privileges to be able to read files in bulk without touching their atimes. con: doing this to cover one's tracks (even accessing one's own files), or _only_ for performance reasons, subverts site policy: if the site didn't care about atime, they could have always mounted the filesystem with noatime option; having chosen to have atimes updated, a user shouldn't be able to override that without additional authorization. I suppose one could probably think up more pros and cons for whether or not a mere mortal in their capacity as file owner should be able to read files without atime updates. But even one good one on each side seems to me to be enough, really. Thus, a new privilege, that can either be made available to specified commands via suitable RBAC rules and one of the pf* shells, or in special cases assigned to accounts (let's say you have an indexer that runs in a unique user and group so that it can only index publically readable files), or even added to every user's perms when their account is created, as the site chooses. That satisfies both pros and cons, and having the lack _only_ of the new privilege (as contrasted with the lack of owner or owner-like privilege) cause O_NOATIME to be ignored silently keeps the behavior compatible with Linux (which I gather doesn't have an additional "capability" (their term for what we call a privilege, I think) specifically to control O_NOATIME but acknowleges that O_NOATIME may not work for all filesystems (and therefore apps already have to deal with the possibility that it may silently not work). The only things I can see against introducing a new privilege are: * additional complexity * a tiny amount of additional overhead doing open(2) and fcntl(2) (to validate the permissions) * an even smaller amount of overhead for each read(2) (to check whether the flag was set and alter behavior accordingly) The only problem I can see with ignoring the flag silently given only the lack of the new privilege is that requesting it and then later retrieving open flags with fcntl() would show it cleared; one could (with more complexity) have some hidden flag to say that it was to be ignored even though set, and thus be able to have fcntl() return it even when it was ignored, but IMO it's hardly worth the bother to go _that_ far in the name of compatibility with Linux, esp. since with a new permission one actually would be behaving differently. In fact, that slightly different behavior could be beneficial if an app _wanted_ to know that the O_NOATIME flag was being ignored due to lack of the extra privilege. Absent making retrieval of an ignored O_NOATIME open flag transparent, and aside from the changes involved in simply defining any new priv, I don't see that actually enforcing the new priv takes more than a handful of lines of code, so I don't think the complexity would be burdensome. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
