* Martin D Kealey ([EMAIL PROTECTED]) [081202 04:37]:
> On Tue, 25 Nov 2008, Dave Whipp wrote:
>
> sub setstat(String|File $filename, StatBuf $stat) {
> ...
> if $caps.CAP_FOWNER {
> # we're privileged, so it *should* just work.
> POSIX::chown $filename, $stat.uid, $stat.gid;
>
On Tue, 25 Nov 2008, Dave Whipp wrote:
> Brandon S. Allbery KF8NH wrote:
> > Still misunderstanding, I think. Yes, it will fail anyway, but in the
> > general case you're checking to see if as a privileged process it is safe to
> > operate on a given file.
>
> I'd actually been thinking that one w
* Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> [2008-11-25 07:25]:
> OTOH Perl has historically not said much about doing that kind
> of thing.
And I’m not in favour of it starting now. All I am saying is that
APIs should be designed to encourage correct designs; arguably
this is the spirit of Per
Brandon S. Allbery KF8NH wrote:
Still misunderstanding, I think. Yes, it will fail anyway, but in the
general case you're checking to see if as a privileged process it is
safe to operate on a given file.
I'd actually been thinking that one would use the check in the opposite
direction:
if
On 2008 Nov 24, at 10:45, dpuu wrote:
PS. From S16, q{ ... On POSIX systems, you can detect this condition
this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
}
From this I inferred that the purpose of this assignment was to do a
On 2008 Nov 24, at 10:36, dpuu wrote:
On Nov 23, 3:56 pm, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH)
wrote:
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 o
On Nov 23, 4:55 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote:
> 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.
Neither do I. Catching Failure objects is better th
On Nov 23, 3:56 pm, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH)
wrote:
> 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
* 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
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
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 h
* 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 e
* dpuu <[EMAIL PROTECTED]> [2008-11-21 19:00]:
> The definition of C 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
> f
On Nov 22, 12:46 am, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH)
wrote:
> On 2008 Nov 21, at 14:13, Dave Whipp wrote:
>
> > The restriction of chown to the superuser is a property of the OS,
> > not the files. The example from the pod is:
>
> man pathconf
Ah, thanks for that.
It's probably an
On 2008 Nov 21, at 14:13, Dave Whipp wrote:
The restriction of chown to the superuser is a property of the OS,
not the files. The example from the pod is:
man pathconf
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many ha
On 2008 Nov 21, at 13:20, Larry Wall wrote:
On Fri, Nov 21, 2008 at 09:57:30AM -0800, dpuu wrote:
: On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
: > Please feel free to whack on the spec
: The definition of C includes the statement that it's not
: available on most system unless you'
Larry Wall wrote:
On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote:
: before I attempt to change the POD, would this wording be appropriate?
It's a good first whack, though we might want to think about making
it a little less P5ish/Unixish in changing a list of files, and rely
instead of one
gt;
To: dpuu <[EMAIL PROTECTED]>
Cc: perl6-language@perl.org
Sent: Friday, November 21, 2008 10:30:08 AM
Subject: Re: S16: chown, chmod
dpuu wrote:
> Question: is it appropriate to P6 look&feel to have methods on
> functions?
I don't think that's such a good idea in this case
On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote:
: before I attempt to change the POD, would this wording be appropriate?
It's a good first whack, though we might want to think about making
it a little less P5ish/Unixish in changing a list of files, and rely
instead of one of P6's distributio
before I attempt to change the POD, would this wording be appropriate?
=item chown
our multi chown (Int $uid, Int $gid, Str|IO [EMAIL PROTECTED])
our multi chown (Str $user, Str $group, Str|IO [EMAIL PROTECTED])
Changes the owner (and/or group) of a list of files. The new
ownership can b
Larry Wall wrote:
> On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote:
> : For chmod() I could imagine an interface like this:
> :
> : $file.chmod(:8<540>);
> : $file.chmod( :set, :user => :r & :x, :group => :r)
> :# both same as 'chmod 540 $file'
> :
> : $file.chmod( :modifiy,
On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote:
: For chmod() I could imagine an interface like this:
:
: $file.chmod(:8<540>);
: $file.chmod( :set, :user => :r & :x, :group => :r)
:# both same as 'chmod 540 $file'
:
: $file.chmod( :modifiy, :other => :!x)
:# same as
dpuu wrote:
> Question: is it appropriate to P6 look&feel to have methods on
> functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
> The definition of C includes the statement that it's not
> available on
On Fri, Nov 21, 2008 at 09:57:30AM -0800, dpuu wrote:
: On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
: > Please feel free to whack on the spec
:
: OK, working on it.
:
: Question: is it appropriate to P6 look&feel to have methods on
: functions?
:
: The definition of C includes the
On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
> Please feel free to whack on the spec
OK, working on it.
Question: is it appropriate to P6 look&feel to have methods on
functions?
The definition of C includes the statement that it's not
available on most system unless you're superuser
On Fri, Nov 21, 2008 at 08:44:51AM -0800, dpuu wrote:
: Reading S16, I was struck by the lack of abstraction over the
: underlying Unix API for chown and chmod. Nothing wrong with having the
: existing functions lying about in a module that people can "use Unix"
: for; but I do feel that the varian
Reading S16, I was struck by the lack of abstraction over the
underlying Unix API for chown and chmod. Nothing wrong with having the
existing functions lying about in a module that people can "use Unix"
for; but I do feel that the variants in the global namespace should be
more user-friendly.
chow
27 matches
Mail list logo
