After creating a logical name "olmteste"

define/exec olmteste "teste"

tried to remove with "deassign olmteste" but returning
%SYSTEM-F-NOLOGNAM, no logical name match

sh log olmteste
"OLMTESTE" = "teste" (LNM$PROCESS_TABLE)

The logical name is in the process_table that's the default table that the deassign search's so shouldn't need to specify the table "deassign/process olmteste" but even specifying get the same message of no match.

when close the console that logical name is removed as expected since its in the process table.

Just don't get why can't remove manualy with deassign, when with supervisor mode can remove without a probleam.

Note: tried in eisner.decus.org and even with executive mode could remove with sucess using deassign, so assuming that the environment that made the test must have some extra validation in deassign but just a guess.

does exists a default command procedure or file that can have some personalized rules for deassign remove of logical names?

On Thursday, October 21, 2021 at 10:44:32 AM UTC-4, HCorte wrote:
> After creating a logical name "olmteste"
>
> define/exec olmteste "teste"
>
> tried to remove with "deassign olmteste" but returning
> %SYSTEM-F-NOLOGNAM, no logical name match
>
> sh log olmteste
> "OLMTESTE" = "teste" (LNM$PROCESS_TABLE)
>
> The logical name is in the process_table that's the default table that the deassign search's so shouldn't need to specify the table "deassign/process olmteste" but even specifying get the same message of no match.
>

Default is supervisor mode... yours is executive mode, so you need to indicate that when deassigning.

$ deassign/executive_mode olmteste

A quinta-feira, 21 de outubro de 2021 à(s) 15:57:45 UTC+1, Jim escreveu:
> On Thursday, October 21, 2021 at 10:44:32 AM UTC-4, HCorte wrote:
> > After creating a logical name "olmteste"
> >
> > define/exec olmteste "teste"
> >
> > tried to remove with "deassign olmteste" but returning
> > %SYSTEM-F-NOLOGNAM, no logical name match
> >
> > sh log olmteste
> > "OLMTESTE" = "teste" (LNM$PROCESS_TABLE)
> >
> > The logical name is in the process_table that's the default table that the deassign search's so shouldn't need to specify the table "deassign/process olmteste" but even specifying get the same message of no match.
> >
> Default is supervisor mode... yours is executive mode, so you need to indicate that when deassigning.
>
> $ deassign/executive_mode olmteste

Thanks Jim,

that's it got the wrong edia... that only needed to specify the table only in case it wasn't default one "process" in use.

On 2021-10-21 14:44:30 +0000, HCorte said:

> After creating a logical name "olmteste"
> ...
> does exists a default command procedure or file that can have some
> personalized rules for deassign remove of logical names?

Logical names can translate from any table in the default list of
logical name tables and in the table order specified, and translated
from modes in ascending order of least to most privilege in each table.

First translation wins, the rest get ignored.

Creation and deletion of privileged-mode logical names involves
privileges (CMEXEC, CMKRNL, etc), and involves explicit specification
of mode.

If the logical name is not in the default searchlist of tables, the
table of residence will need be explicitly specified.

Logical name translations can be restricted to trusted modes by
explicit request (usually for security), or by operating in certain
trusted contexts (for security), or by selecting a list of tables to
translate from. This because the first translation wins, which can be
entirely untrusted and least-privileged translation if not otherwise
restricted during the logical name translation request.

Logical name tables can be protected by protection
(S:RWED,O:RWED,G:RWED,W:RWED) bitmask and by access control list. The
tables are considered security objects, for the purpose of OpenVMS
security.

Logical name translations have a chaotic little feature of ignoring
leading underscores in various translation contexts, sort of. This was
supposedly a means to restrict translations to physical devices (which
can have a leading underscore), but it doesn't work that way now. The
overhaul at VAX/VMS V4.0 didn't fully implement what earlier and
simpler logical name implementations had provided here: in earlier
versions, a leading underscore had stopped translations. Now that's
sorta-kinda the concealed and terminate options on the logical name
definition.

This whole area all works rather similar to the logical-name based
searchlist logical names used for the system disk too, with the added
wrinkle of needing to create directories in each translation lest
errors arise for some operations. You read from all translations, you
write to the first translation. (This is how inexperienced cluster
system administrators can fill their cluster roots with files too,
while intending to share the files from within the common root.) To
get these to work, parallel the translation options on SYS$SYSROOT and
related translations, as the correct operation of searchlist logical
names are entirely dependent on the specified translation options.

Logical names are a bad means of providing configuration information to
apps past temporary and transient device and file redirections, not
that OpenVMS has looked at this area since VAX/VMS V4.0 or so, and not
that OpenVMS has really looked at app-level context APIs and features
for that matter. Logical names for app management purposes past device
and file redirections do have virtue of being simple for the developer
to start using and harder to properly implement and far harder quit,
which is why we've been enjoying bad app configuration management
interfaces ~everywhere on OpenVMS for decades. Once you see how awful
logical names really are as compared with purpose-built app
configuration APIs, seeing the logical names used everywhere is...
frustrating.

I'd suggest having a look at the OpenVMS User's Manual and the OpenVMS
Programming Concepts manuals for some background in the lower-level
platform features. The manuals are scattershot around coverage of
specific topic areas, such as logical names; "recipe" or "cookbook"
stuff from that era was usually provided over in the support database,
and that material was slowly or variously never incorporated into the
documentation information design.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-10-21, HCorte <hmmbcorte@gmail.com> wrote:
>
> Note: tried in eisner.decus.org and even with executive mode could remove with sucess using deassign, so assuming that the environment that made the test must have some extra validation in deassign but just a guess.
>

Assuming you are not privileged on Eisner, it wasn't created as an
executive mode logical, but it was silently converted to a supervisor
mode logical.

Personally, I think you should get a not sufficiently privileged error
message in that case and not a silent conversion to supervisor mode.

If you could create an executive mode logical that you control as
a non-privileged user, then congratulations, you would have earned
yourself a CVE number. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/21/2021 1:55 PM, Simon Clubley wrote:
> On 2021-10-21, HCorte <hmmbcorte@gmail.com> wrote:
>>
>> Note: tried in eisner.decus.org and even with executive mode could remove with sucess using deassign, so assuming that the environment that made the test must have some extra validation in deassign but just a guess.
>>
>
> Assuming you are not privileged on Eisner, it wasn't created as an
> executive mode logical, but it was silently converted to a supervisor
> mode logical.
>
> Personally, I think you should get a not sufficiently privileged error
> message in that case and not a silent conversion to supervisor mode.
>
> If you could create an executive mode logical that you control as
> a non-privileged user, then congratulations, you would have earned
> yourself a CVE number. :-)
>
> Simon.
>

Some years ago (many) there was an interesting upgrade for DCL request.

"Do what I mean, not what I type" ...

DCL should have kicked the define statement back as an error, since the OP
did not have EXEC privs, and added the /EXEC switch.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486