On Tue, 11 Nov 2003 09:46:31 EST, "Serge E. Hallyn" said:
>> Likewise, I can't convince myself that the fact that a given dentry can be either
>> on the read exception list or execute exception list, but not both, isn't a whoops
>> waiting to happen.
> That is easy enough to fix, but at a (perhaps very minor) performance hit.
> I'm undecided as to whether that would be a good thing. It seems to perhaps
> be tempting the administrator into using this module too generally?
Well, I wasn't able to figure out by inspection at 3AM whether it DTRT for
code that used #! (shell/perl scripts) that need both read and exec access (exec to
get the #! interpreter launched, then read so the interpreter can read the script).
After the exec, you're running something that's on the exec exceptions list, but
still tagged with the jail, which should prevent reading the file (except I think
the kernel keeps a fd open across #! processing to address this issue), but I've
seen a lot of Perl that has some ad-crockery at the front to re-exec Perl if
it manages to get invoked as a shell script... (the Perl docs even have this gem:
`-S'
makes perl use the `PATH' environment variable to search for the script
(unless the name of the script starts with a slash). Typically this is used to
emulate `#!' startup on machines that don't support `#!', in the following
manner:
#!/usr/bin/perl
eval "exec /usr/bin/perl -S $0 $*"
if $running_under_some_shell;
The system ignores the first line and feeds the script to `/bin/sh', which
proceeds to try to execute the perl script as a shell script. The shell
executes the second line as a normal shell command, and thus starts up the perl
interpreter. On some systems `$0' doesn't always contain the full pathname, so
the `-S' tells perl to search for the script if necessary. After perl locates
the script, it parses the lines and ignores them because the variable
`$running_under_some_shell' is never true. A better construct than `$*' would
be `${1+"$@"}', which handles embedded spaces and such in the filenames, but
doesn't work if the script is being interpreted by csh. In order to start up sh
rather than csh, some systems may have to replace the `#!' line with a line
containing just a colon, which will be politely ignored by perl. Other systems
can't control that, and need a totally devious construct that will work under
any of csh, sh or perl, such as the following:
eval '(exit $?0)' && eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
& eval 'exec /usr/bin/perl -S $0 $argv:q'
if 0;
*gaak*. ;)
(Note that if some bozo says "sh /whatever/proggie", that bypasses the #! handling
and it gets launched as a shell script, so all the above can be applicable on
systems that support #!....)
This archive was generated by hypermail 2b30 : Tue Nov 11 2003 - 21:08:43 PST