Re: S16: chown, chmod
* dpuu [EMAIL PROTECTED] [2008-11-21 19:00]:
The definition of Cchown includes the statement that it's not
available on most system unless you're superuser; and this can
be checked using a POSIX incantation. I was wondering if it
would be reasonable to provide this as a method on the chown
function, so that a user could say:
if chown.is_restricted {
...
}
else {
chown $user, $group == @files
}
As has been mentioned by others this is a bad idea. All atomic
operations on filesystems boil down to attempting an operation
and dealing with the fallout if it fails. Attempting to check
whether an operation will succeed prior to attempting it almost
invariably leads to broken code. (Worse: subtly broke code, in
most cases.)
The API you propose does not seem to me to shorten code at all
and is likely to lead to problematic code, so it seems like a
bad idea. Interfaces should be designed to encourage people to
do things correctly and to make it hard to even think about the
nearly certainly wrong way.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: S16: chown, chmod
* Larry Wall [EMAIL PROTECTED] [2008-11-21 23:55]:
Any you could even do it in parallel:
my @status = hyper map { .io.chmod($mode) }, @files
though it's possible your sysadmin will complain about what
you're doing with the disk drive heads. :)
Actually I/O subsystems are smart enough these days that this
might be a sensible thing to do. It would distribute to multiple
disks without much affecting the single-disk case.
Over on the git list, Linus Torvalds just implemented naïvely
threaded `stat`ing for certain cases in `git log` and `git diff`,
and people with git repositories on NFS filesystems reported
3–6-fold speedups of these commands, without the local case being
adversely affected.
/offtopic-diversion
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: S16: chown, chmod
On Nov 23, 2:33 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote: The API you propose does not seem to me to shorten code at all and is likely to lead to problematic code, so it seems like a bad idea. Interfaces should be designed to encourage people to do things correctly and to make it hard to even think about the nearly certainly wrong way. I'm going to both agree and disagree. I agree that the specific example of chown.is_restricted is a bad idea, but only because the POSIX API I was wrapping is itself flawed. In general I would continue to pursue the approach of adding precondition-checks as methods on functions, a concept that is orthogonal to the specific example you are arguing against: I disagree that the code I showed is not simpler that the original S16 approach.
Re: S16: chown, chmod
On 2008 Nov 23, at 18:35, dpuu wrote: On Nov 23, 2:33 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote: The API you propose does not seem to me to shorten code at all and is likely to lead to problematic code, so it seems like a bad idea. Interfaces should be designed to encourage people to do things correctly and to make it hard to even think about the nearly certainly wrong way. I'm going to both agree and disagree. I agree that the specific example of chown.is_restricted is a bad idea, but only because the POSIX API I was wrapping is itself flawed. In general I would continue I think you're seeing something other than what we are. Checking any external resource before operating on it introduces a race condition which can allow an attacker to swap resources on you, so the item you (in this case) chown() isn't the one you tested. (In this case, if you're chown()ing to root, an attacker might substitute a shell for the file you tested.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: S16: chown, chmod
* dpuu [EMAIL PROTECTED] [2008-11-24 00:40]: I agree that the specific example of chown.is_restricted is a bad idea, but only because the POSIX API I was wrapping is itself flawed. It is not flawed in the least, as far as the aspect we are talking about is concerned. (It is generally sane in far more ways than it is flawed.) In general I would continue to pursue the approach of adding precondition-checks as methods on functions, a concept that is orthogonal to the specific example you are arguing against In general? Sure. But for filesystem operations? Bad idea. I disagree that the code I showed is not simpler that the original S16 approach. I don’t see any examples in S16 concerning error handling anyway, but even so I don’t see how relying on exceptions would could possibly be more complex than guard clauses. You *still* have to handle errors after the guard clause passes and the operation is attempted. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
