At 7:54 PM -0500 11/25/01, Charles Bailey wrote:
>Craig A. Berry <[EMAIL PROTECTED]> wrote:
> >
> > 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
BTW, I believe this could be turned into a trappable error rather
than bombing out by this change:
--- vms.c;-0 Mon Nov 19 08:30:06 2001
+++ vms.c Sun Nov 25 22:09:16 2001
@@ -733,7 +733,7 @@
case LIB$_INVARG: case LIB$_INVSYMNAM: case SS$_IVLOGNAM:
case LIB$_NOSUCHSYM: case SS$_NOLOGNAM:
set_errno(EINVAL); break;
- case SS$_NOPRIV:
+ case SS$_NOPRIV: break;
set_errno(EACCES);
default:
_ckvmssts(retsts);
[end]
Was the omission of "break" intentional or just a typo?
> >
>> 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.
Well, every time I think about trying to change it, I usually
conclude that it's not easy to come up with a better balance than
what we have now. The reason this has come up is that people keep
wanting to put code in the test suite that looks like
delete $ENV{HOME} while exists $ENV{HOME};
which, if HOME exists in LNM$SYSTEM_TABLE and the user does not have
privs will either blow up on the first try, or, if the missing
C<break;> mentioned above is added, result in an endless loop.
> > 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()),
Wait, isn't that what we have now?
>or keep trying down the list in both cases
>until we succeed or hit the end of the list.
I think we do this now with deletes, and as you point out, writes
will succeed the first time, at least if using LNM$FILE_DEV.
>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.
I agree we should use some abstraction rather than special casing
specific tables. I'm not that experienced with sys$check_access, but
it looks like we can find out what privs are required to perform a
particular operation on a particular logical name table. This would
allow us to do the right thing on a system that has custom logical
name tables, at least if we can figure out what the "right thing" is
in the general case. Probably a warning or error, possibly
disallowing the operation altogether if a pragma is in effect (or a
configuration choice has been made). Looks like the first step is to
write a Perl_cando_logical() function.
>
> > 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]
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall
