run/uic= does not start process as other user

[Wim Van den Wyngaert]

I guess that if they don't know we need "su -" they don't understand what we need. A request won't change that.
A good manager might ...

Wim

[Antoniov.]

Hi,
Hunter Goatley is known in vms world; also in Freeware CD there are another software to login with another user called JUMP.
For freeware you can ask support to developer (I guess he's happy to do this).

Antonio Vigliotti

[Jan van den Ende]

Wim (& Uwe, Antonio)

the one thing I would ABSOLUTELY need to go with "su-" is a very rigorous authentication, accounting, and audit on it!
"su-" as in *X just has way to little constraints and traceability.

(And on a vaguely related topic: in VMS I would like to be able to see who issued a SUBMIT/USER= )

Jan

[Antoniov.]

On freeware V4
http://h71000.www7.hp.com/openvms/freeware/index.html
there was a software called kronos that's a cron emulator.
Tim, you could see on it may give some idea.

Antonio Vigliotti

[Willem Grooters]

Though this is off-topic:

I have had REALLY BAD experiences with su in Unix. When you have a lot to do, and certainly in a very stressfull environment, it's easy to forget you did su. With all consequences...In my case, the whole system was blown to pieces, just because of this. and there was no way to find out who did it...

Actually, if we had something like
$ RUN/IMPERSONATION= ....
to run just THAT image under that user's account, that would be sufficient IMHO.
Still wthin this, I double Jan's suggestions.

I would put even more restrictions:

At least "IMPERSONATE" privilege would be required. But additionally, you need GRPPRV to switch to another with your group and SYSPRV to any other - which means typically system-group users.

However, considering "root" in Unix terms equals VMS's "SYSTEM", it should NEVER be allowed to impersonate any account in a group where grp <= MAXSYSGROUP. Why would you: If you could, there is no need to do that, you can login that way!
(With one exception, perhaps: if your groupnumber is <= MAXSYSGROUP, when you have both SYSPRV and GRPPRV. It can be handy - but just that!)

If interactive "su" is implemented, all above applies, but I think it wise that default privileges should be as low as possible. Just enable authorized privilges is needed. Also, there must be a clear warning that you "su"'d, ON ANY PROMPT, which cannot be undone. I don't care in what format!
And PLEASE give it a decent name....

Willem

[Jan van den Ende]

Willem,

I mostly agree, but:


However, considering "root" in Unix terms equals VMS's "SYSTEM", it should NEVER be allowed to impersonate any account in a group where grp <= MAXSYSGROUP. Why would you: If you could, there is no need to do that, you can login that way!
(With one exception, perhaps: if your groupnumber is <= MAXSYSGROUP, when you have both SYSPRV and GRPPRV. It can be handy - but just that!)


Here I totally DON'T agree!
If there is a need (real need, not just lazyness of the programmer) to have a certain function running as SYSTEM, (by definition <= MAXSYSGROUP ) then that SHOULD be possible, (well traceble of course).
And your idea about it only being allowed if the issuing process itself is <= MAXSYSGROUP, _THAT_ I abhorr. It implies that users (as in system managers, who are also only fallible mortals) are LOCKED into an environment with effectively SYSPRV always ON. To me, that looks like a very unwanted situation.
Even IF you have the impression that you are in a position to "always" want it, it might still be usefull to be able to turn it off, if only to test that error reports might or might not be a protection issue...

And your horror story about su- can also be told about VMS systems with multiple people using the SYSTEM account.

jpe

[Tim Nelson]

Here is the real life situation that may help tie this all back together.

A detached process needs to be started at boot time. ( I am assuming all boot sequences and scripts run by default as the SYSTEM user).
This detached process does not need or perhaps requires less privs, different quotas or other environment. (i.e. a scheduler program.)
In the UNIX world cron is started and run under the root id and environment. Cron then executes what is in the schedule using the individual users id and evironment of he who created the submission to the schedule.
With this said. It may be more advantageous in my case to make changes to the scheduler program and use submit/username instead of trying to force a solution into the run/detached for the main scheduler.
Although it seems that su in the VMS world is a highly discussed topic.
Thanks again to all for your experiences and opinions.
Tim

[Willem Grooters]

Tim,

Given your explanation, consider this:

Cron in Unix can be compared to QueueManager in VMS. One (minor) difference is that cron includes a scheduler. In VMS, each job has to reschedule itself, or needs additional software to have it scheduled automatically.

In prinicple you could define a queue "Scheduler", owned by UIC "cron" on which you run the cron.com job (running the cron_daemon proces), or some job that issues the run/detach command you described. This submit command to be done /USER=CRON (or whatver user you require). You can set the whole thing up in such a way that the CRON proces is automatically started whenever the current process (or system) crashes, or after boot.

Willem

[Tim Nelson]

Thanks.. That should cover it..

Appreciate everyone's input.

Have a great weekend.

[Lawrence Czlapinski]

/detach "Creates a process with the same user identification code (UIC)as the current process. To create a detached prcoess with a different UIC, use the /UIC qualifer.) So there is a conflict between the /detach and /uic. Try it without the "/detach -"

[Uwe Zessin]

Lawrence,
you are missing the point. Tim wants to run a detached process under a different USERNAME and you can't do that with RUN. Please re-read the entire thread.

[Lawrence Czlapinski]

As Tim said, put your RUN command in a .COM file and SUBMIT/USER=CRON. CMKRNL privilege is needed if submited from a different account.
I didn't mean to imply that leaving out /detach would run the process under a different username. I just meant that the documentation on RUN says that /detach (same UIC) and /UIC flags conflict. Depending on the way VMS processes the flags you could get unexpected results. One would expect the last of the two to cancel out the other but I wouldn't count on it.

[Jan van den Ende]

.... and that means you would expect the command parser to return an error when you try, but it just creates a process...


Jan

[Tim Nelson]

Thanks to all who responded