On Thursday, November 02, 2006 10:03:25 PM -0600 Mike Gerdts <mgerdts at gmail.com> wrote:
> However, sync(1m) could > do the same check that sync(2) does and return the appropriate error. Ugh! No, thank you. I already see enough trouble with programs that think they "know" what the privilege model is and refuse to run if, say, the UID is not 0, or the mode on some file is not what that (ACL-unaware) program expects, or whatever. As a filesystem developer, I've seen the same problem with OS's whose VFS layer decides that the user won't be able to change some property of a file because his uid is not the same as the file's, and returns an error without ever bothering to pass the operation to the filesystem. Guessing whether you are allowed to do something and then not bothering to try if the answer is "no" will always come back to bite you, or someone. > 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission > Denied" and exit with a non-zero value if the permission is not held. No. If you print "Permission Denied", it better be because some syscall return EPERM. Don't fake it. IMHO, it's better for sync(1m) to silently do nothing than to print a bogus error message for an operation it never tried. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
