Open DabeDotCom opened 1 year ago
A pull request would be welcomed.
I don't think the control over read vs write vs subprocess is something that's going to be resolved anytime soon, and if it is, it wouldn't be via Opcode, since this is a problem that occurs after the op is dispatched.
It might be possible to solve this via the PERL_IMPLICIT_SYS mechanism, but that's effectively a Windows only thing.
Module: ops / Opcode / Safe
Description
I'm sure this has to be a known deficiency, but I was trying to figure out if I could allow an app to accept untrusted data but not do TOO much damage, when I was surprised/disappointed to discover that
perl -Mops=":default,open"
still allowed me toopen my $FH, "|-" => "shell command"
— even though:subprocess
was still denied!(Most users, myself included, don't immediately grasp the distinction between parse/compile-time opcodes and underlying system calls (
man 2
) and C library functions (man 3
); heck, very few people even understand / care about the distinction betweenman 2
andman 3
, haha!)Anyway, I'm guessing that, if there were an easy fix, not only would
"|-"
and"-|"
be treated differently, but so would>
and>>
, etc. (By which I mean, it can permit/deny theopen
keyword wholesale, but not, for example, permit individual "open for reading" operations and deny "open for writing" requests — short of definingopen_r
,open_w
, andopen_x
-type opcodes, which may or may not be known at compile time, and so on.)Probably my best suggestion, therefore, would be to add a warning to the
:filesys_open
or:filesys_write
sections ofperldoc Opcode
, making sure people realize that just because you deny:filesys_write
doesn't mean you're actually preventing all write-access to the filesystem... «shrug» I'd be happy to write a PR with such a paragraph, if you want.Steps to Reproduce
As expected, calling
open()
with only-Mops=:default
dies correctly: (The crazy redirection and whatnot is so I can limit the reduce the list of permitted ops to a bare minimum)Whereas adding
open
makes it execute thetouch
command:Even in
docker run perl:latest
:This is somewhat unexpected, since
system()
also dies "correctly":Expected behavior
"Expected" might be a strong word... I was hoping it would be clever enough to block the
system()
(and/orpipe() / fork() / execve()
etc.) calls as well.Like I say, the end result of this whole exercise may just be adding a warning to the documentation... «shrug»
Perl configuration
This is straight out of
docker run --rm perl:latest perl -V
(perl:5.36.1)Cheers! :-D