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

Reply via email to