Craing A. Berry <[EMAIL PROTECTED]> wrote:
>
> A few days ago I said on vmsperl, "Writing to or deleting from %ENV
> only affects the PROCESS table." I still think this is true with
> regard to writing, but it does not appear to be with regard to
> deleting.
>
> Here's how it works with writing. Assuming we are using logicals
> (and not the C RTL env or symbols) to handle %ENV, setting a value
> always, as far as I can tell, puts it in the process table:
>
> $ show logical foo
> "FOO" = "SYSFOO" (LNM$SYSTEM_TABLE)
> $ perl -e "$ENV{FOO}='BAR';
> $ show logical foo
> "FOO" = "BAR" (LNM$PROCESS_TABLE)
> "FOO" = "SYSFOO" (LNM$SYSTEM_TABLE)
>
> So far so good. I can't accidentally whack the system-level logical
> by setting Perl's %ENV, though I may hide it from my process as long
> as the process logical exists. But deleting works differently. If I
> have the same logical in the process, job, and system tables, I can
> delete them all in turn:
>
> $ show logical foo
> "FOO" = "BAR" (LNM$PROCESS_TABLE)
> "FOO" = "BAZ" (LNM$JOB_8142F5C0)
> "FOO" = "SYSFOO" (LNM$SYSTEM_TABLE)
> $ perl -le "print delete $ENV{'FOO'} while exists $ENV{'FOO'};"
> BAR
> BAZ
> Fatal VMS error (status=36) at D0:[CRAIG.PERL]VMS.C;1, line 739 at -e line 1.
> %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
>
> It deletes from least privileged to most privileged, which is not a
> surprise, but it did surprise me that it would go ahead and attempt
> to delete from the system table. If I have SYSPRV enabled, it will
> succeed.
>
> Should we allow this? This seems risky behavior on a couple of
> counts. I can delete from a place that I can't write to, and I have
> no way of knowing what table I'm attempting to delete from.
>
> Some alternatives:
>
> 1.) Leave it as is. We are protected by the normal VMS privilege scheme.
It was tough to figure out a consistent way to approach this. I went with the
current setup so that when one set up PERL_ENV_TABLES, one would know with some
certainty what table might have new values added (we only try to write to the
first table in this list), but would have the best shot at clearing out
unwanted values, without much of a security hole in the case of unprivd
processes. What I hoped was a gain in utility may be a pain in consistency.
> 2.) Disable deleting from LNM$SYSTEM_TABLE and LNM$CLUSTER_TABLE.
If we do change the current behavior, I'd suggest one of two options: either
write/delete only to the first table in PERL_ENV_TABLES (which does retain some
apparent inconsistency in the default case, since this is LNM$FILE_DEV, so
writes will always succeed into the process table, while deletes may quietly
propagate out in sys$dellnm()), or keep trying down the list in both cases
until we succeed or hit the end of the list. I think this might give more
flexibility than making LNM$SYSTEM_TABLE and LNM$CLUSTER_TABLE special (and
also avoid the problem of having to ferret them out of LNM$FILE_DEV and the
like); we can rely on VMS privs to protect the unwary here.
> 3.) Disable deleting as in #2 but allow it to be reenabled via a
> pragma (use vmsish 'privlognam' ?).
Always an option, especially for compatibility's sake.
> 4.) Check to see if deleting a logical would require privs, and
> throw a warning if it does.
At the least, be fussy about taint checks.
Regards,
Charles Bailey [EMAIL PROTECTED]
