Code: Select all
HSQX86$ dir dka0:[000000]000000.dir/dat
Directory DKA0:[000000]
000000.DIR;1 insufficient privilege or object protection violation
Total of 1 file.Code: Select all
> What could be wrong?
I'd guess that someone made undesirable changes to the standard VMS
UIC and GROUP values, defeating the usual expectations.
> [...] Now I created another account, let's call it User and assigned
> all rights to it [...]
Not a very detailed description of this new account.
> [...] Then I changed the System's UIC from [1,1] to [41,1] [...]
Moving SYSTEM from (special) group 1 to (ordinary) group 41?
https://wiki.vmssoftware.com/UIC
[...] VSI reserves group 1 and groups 300-377 for its own use.
> [...] according to our system configuration requirements. [...]
Elaborate? Hint: Explain your actual requirements, not how you
believe the VMS configuration should be changed in order to satisfy
these (unspecified) requirements.
> [...] What I am facing now looks strange: [...]
So does what can be seen of your modified configuration. (File
ownership, for example, is invisible.)
"Doctor, it hurts when I do this."
"Don't do that."
Code: Select all
UAF> sho hsq
Username: HSQ Owner: HSQ
Account: MISER UIC: [41,1] ([MISER,HSQ])
CLI: DCL Tables: DCLTABLES
Default: SYS$SYSDEVICE:[USERS.HSQ]
LGICMD: LOGIN
Flags:
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 8 Login Fails: 0
Pwdlifetime: (none) Pwdchange: (pre-expired)
Last Login: 26-OCT-2023 09:38 (interactive), 26-OCT-2023 12:39 (non-interactive)
Maxjobs: 0 Fillm: 400 Bytlm: 46400
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 350 JTquota: 10240
Prclm: 16 DIOlm: 350 WSdef: 20480
Prio: 4 ASTlm: 350 WSquo: 81920
Queprio: 4 TQElm: 100 WSextent: 20480
CPU: (none) Enqlm: 6400 Pgflquo: 800000
Authorized Privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE
SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX
UPGRADE VOLPRO WORLD
Default Privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE
SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX
UPGRADE VOLPRO WORLDCode: Select all
> 2. I realize that it might be not a good idea to change the System's
> group, [...]
An explanation of the reason might be interesting.
> [...] the system we have been shipping for 30+ years was always
> configured that way: [...]
That'd be suggestive, at least.
> [...] Yes this is a new VMS version and it is possible it treats it
> different, [...]
Very (perhaps too) generally, VMS is VMS, so I wouldn't bet on that.
> [...] however it seem violating the rules. [...]
Perhaps. Perhaps not. In my (limited) experience, it's certainly
unusual/startling.
One other potentially interesting item I stumbled into while
searching this new Inter-Web thing:
https://wiki.vmssoftware.com/UIC_Protection
System refers to users with the UIC group of 0 through the value
of MAXSYSGROUP (10 by default; bear in mind that numbers in a UIC
are octal). [...]
Around here, it's always the default:
ITS $ mcr sysgen show MAXSYSGROUP
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
MAXSYSGROUP 8 8 1 32768 UIC Group D
I've never touched it, so I know nothing, but if you haven't jacked
MAXSYSGROUP up to at least 33 (%o41), then I'd give that a shot.
How complete/reliable is the system-mutilation procedure that you're
following?
It might also be interesting to see the characteristics (including
ownership and protections) of the MFD ("[000000]000000.DIR") and/or
other top-level stuff on the system volume.