> Richard L. Hamilton writes: > > Right, but but I was thinking that an extra priv > should be required, > > since this would override POSIX and/or mount-time > policy, > > obfuscate forensics, etc. > > Allowing willing applications to step outside of the > confines of POSIX > -- even if their doing so may deny POSIX-compliant > applications from > gathering information they desire (such as access > time) -- doesn't > seem like a sufficient reason to me to assign a > privilege. POSIX is > one of many environments we support, and I wouldn't > want to build a > moat around it.
I agree, although somehow the "mount-time policy" aspect seems to have slipped out of your response. Some sites are policy-happy and would probably regard any new freedom of action that couldn't be locked down as a potential threat just out of habit. Whether they're right to do so is irrelevent - it's their expectations that matter. Perhaps they're recognizing their limitations: they know they're not qualified (or not prepared to pay for the effort) to _properly_ evaluate the issues, and as no-brainers go, deny is usually safer than permit. > The "obfuscating forensics" argument is a much better > one. It's hard > to imagine how anything other than a file-based > system backup utility > could have a valid reason to avoid the access time > update. The > remainder of users would be hackers attempting to > obscure their trail > and lame applications trying to get a "performance > edge." Right - and I've had an occasion or two to appreciate the use of time stamps to reconstruct what must have happened, so I'd just as soon that not just anyone could keep them from being updated. The Linux docs mention one other example: a file indexing service, perhaps for a desktop-wide search facility. > This capability seems to me to be pretty closely > related to > PRIV_FILE_DAC_READ and PRIV_FILE_OWNER. At least, > you'd very likely > need those permissions (or similar) to make use of > this feature. 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. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
