| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 192.1 | What seems to be the problem? | IOSG::TALLETT | Mit Schuh bish hi | Mon Mar 09 1992 09:10 | 12 |
| Hi there!
You don't say what your problem is. You say that the non-privved
account can't access the queue entries - so what? What error do
you get?
A1SUBMIT is for non-privved admin accounts to submit under MANAGER,
(with some security built in). You seem to be doing it the other way
around, so SUBMIT/USER= should be enough.
Regards,
Paul
|
| 192.2 | Queue protection | IOSG::SHOVE | Dave Shove -- REO-D/3C | Mon Mar 09 1992 15:54 | 7 |
| You can add an ACL to the queue, allowing Read access to that user.
Or, if you want all user to be able to see entries on the queue, either
add an ACL specifying user as * or change the queue protection from W:W
to W:RW
Dave.
|
| 192.3 | ACL aids | SNOC02::ZORBASSTUART | NULL Junior | Tue Mar 10 1992 01:42 | 34 |
|
The idea was that some batch jobs (which do some processing and mail
notification) could be executed by a non-privileged account and managed
out of ALL-IN-1 housekeeping.
ALL-IN-1 housekeeping uses A1SUBMIT to submit the batch job, so I
couldn't use other submit methods.
If A1SUBMIT submits a job on behalf of a non-priviled user then that
user cannot read his own entry on the queue, therefore it fails.
A SHOW ENTRY/FULL from a privileged account does not show anything to
why the non-priv User cannot see his own entry. (What magic does
A1SUBMIT perform?)
As .2 pointed out that putting an ACL on the queue now allows the user
to read is own records (as well as everybody elses) and the job runs OK.
But, SMJACKET.COM then tries to create BLP in OA$LIB for a mail message
of it's own, and of course my non-privileged user cannot write to
OA$LIB.
Options:
- Don't use Housekeeping and write my own.
- Give the user privlege
- Use a priviled User (e.g. MANAGER)
- Modify the housekeeping procedures
Cheers,
Stuart
|
| 192.4 | Roll your own | IOSG::TALLETT | Mit Schuh bish hi | Tue Mar 10 1992 08:36 | 61 |
| Hi There!
> The idea was that some batch jobs (which do some processing and mail
> notification) could be executed by a non-privileged account and managed
> out of ALL-IN-1 housekeeping.
>
It would be kinda nice to know a few more details, what sort of
things the job is doing. Might help us suggest alternatives.
> If A1SUBMIT submits a job on behalf of a non-priviled user then that
> user cannot read his own entry on the queue, therefore it fails.
>
You still don't say what fails, or what the actual error text is.
I still don't understand why the job WANTS to read its own queue
entry. Queue entries are read by the Job Controller, not by the
job.
> A SHOW ENTRY/FULL from a privileged account does not show anything to
> why the non-priv User cannot see his own entry. (What magic does
> A1SUBMIT perform?)
>
Well this works for me, I just tried it. The only magic in A1SUBMIT
is that it is installed with privileges, so after doing some
security checks, it does a privileged SEND_JBC, so you can specify
another /USER because it has privs. It should be the same as a
SUBMIT/USER in your case, because the submittor has privs already.
> As .2 pointed out that putting an ACL on the queue now allows the user
> to read is own records (as well as everybody elses) and the job runs OK.
>
Is *READING* all the records a big deal? He can't write the
records.
> But, SMJACKET.COM then tries to create BLP in OA$LIB for a mail message
> of it's own, and of course my non-privileged user cannot write to
> OA$LIB.
>
I don't think SMJACKET was really designed to be used by
non-privved users. If you fix this problem (say by redefining
OA$LIB in the user process to be a searchlist) you may well run
into other problems.
> Options:
>
> - Don't use Housekeeping and write my own.
> - Give the user privlege
> - Use a priviled User (e.g. MANAGER)
> - Modify the housekeeping procedures
>
I don't think you want to give the user privelege (and by the way,
write access to OA$LIB is equivalent to access to the MANAGER
account) and I personally wouldn't modify the housekeeping
procedures (but then I am bias! :-). Using a priv user (MANAGER)
is probably simplest, but I can't tell if that is a security
problem without knowing what you are trying to do. With the info
you have given so far, I would recommend writing your own, and not
trying to use housekeeping.
Regards,
Paul
|
| 192.5 | | SNOC02::ZORBASSTUART | NULL Junior | Wed Mar 11 1992 04:48 | 24 |
|
If, from the ALLIN1 account you:
$ SUBMIT/USER=BLOGGS/AFTER=later....etc
$ A1SUBMIT/USER=BLOGGS/AFTER=later....etc
Then from the BLOGGS (no privileges) account you:
$ SHOW ENTRY
You will see two entries, however, the A1SUBMIT entry will display a
"no privilege".
And as correctly pointed out this did not affect the running of the job
as I first thought.
To get over the other lack of privlege problems (i.e creating the
OA$LIB:.blp) I have given the account privileges until I come up with
something better.
Cheers,
Stuart
|
| 192.6 | Don't understand whats going on here | IOSG::TALLETT | Mit Schuh bish hi | Wed Mar 11 1992 08:06 | 18 |
|
> If, from the ALLIN1 account you:
>
> $ SUBMIT/USER=BLOGGS/AFTER=later....etc
>
> $ A1SUBMIT/USER=BLOGGS/AFTER=later....etc
>
Well that is an excellent test. I can't imagine what the
difference is here. Did you actually submit the same file?
Did show entry show ANYTHING of the A1SUBMIT job, (eg was
it complaining about the protection of the file you submitted
or about the queue entry itself).
Sorry we couldn't help on this one.
Regards,
Paul
|
| 192.7 | OA$ADMIN_DATA for .BLP? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Mar 11 1992 10:02 | 10 |
| Re .5
Sorry if I missed this earlier, but why does the .BLP have to be in
OA$LIB?
Here's an idea for you: The ADMIN_DATA directory (OA$ADMIN_DATA
logical) is writeable by an Administrator, and is specially intended
for this sort of thing. Could you put your .BLP in there?
Graham
|
| 192.8 | Job owner .NE. user to run under (?) | IOSG::SHOVE | Dave Shove -- REO-D/3C | Wed Mar 11 1992 16:42 | 9 |
| I think that it comes down to the owner of the queue entry (which
neither SHOW QUEUE nor SHOW ENTRY show you).
When a job is submitted to run under a different user, I think it's
still owned by the submitting user. So the user under which it's to run
may not be allowed to read it, depending on privs, queue protection
etc.
Dave.
|
| 192.9 | So why does SUBMIT/USER= work? | IOSG::TALLETT | Mit Schuh bish hi | Wed Mar 11 1992 16:45 | 1 |
|
|
| 192.10 | DCL is cleverer, I suppose | IOSG::SHOVE | Dave Shove -- REO-D/3C | Wed Mar 11 1992 16:58 | 7 |
| I suppose DCL SUBMIT sets the owner UIC to the same as that of the user
under which it's to run.
A1SUBMIT doesn't bother, because the poor simple programmer wasn't
aware of this distinction at the time.
Dave (aka Poor Simple Programmer)
|
| 192.11 | X marks the spot | SNOC02::ZORBASSTUART | NULL Junior | Wed Mar 11 1992 23:01 | 35 |
|
re: the OA$LIB:.BLP - it's SMJACKET.COM which creates the BLP in case
of a utility failure. OAUSER sounds like a nice place to generate BLPs.
Any how,
Here are the SHOW ENTRY details.
Job 935 was SUBMITted, job 936 was A1SUBMITted.
From the ALLIN1 account:
Jobname Username Entry Blocks Status
------- -------- ----- ------ ------
X ZORBAS 935 Holding until 12-MAR-1992 12:00
On Batch queue SYS$BATCH
Submitted 12-MAR-1992 08:43 /NOLOG /PRIORITY=100
File: _$2$DUA103:[ALLIN1.SITE.LIB_BRITISH]X.COM;1
X ZORBAS 936 Holding until 12-MAR-1992 12:00
On Batch queue SYS$BATCH
Submitted 12-MAR-1992 08:43 /NOLOG /PRIORITY=100
File: _$2$DUA103:[ALLIN1.SITE.LIB_BRITISH]X.COM;1
From the ZORBAS account:
Jobname Username Entry Blocks Status
------- -------- ----- ------ ------
X ZORBAS 935 Holding until 12-MAR-1992 12:00
On Batch queue SYS$BATCH
Submitted 12-MAR-1992 08:43 /NOLOG /PRIORITY=100
File: _$2$DUA103:[ALLIN1.SITE.LIB_BRITISH]X.COM;1
no privilege 936 Holding until 12-MAR-1992 12:00
|
| 192.12 | You learn something new every day! | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 12 1992 08:23 | 31 |
| Hi there!
I did some experiments:
On VMS V5.4-
sodom$ create x.com
$ Job_num = p1
$ uic = f$getqui ("display_entry", "UIC", Job_num)
$ name = f$getqui ("display_entry", "username", Job_num)
$ show sym uic
$ show sym name
Exit
sodom$ submit oa$lib:sm_restart /after=12:00:00/user=allin1
Job SM_RESTART (queue SYS$BATCH, entry 672) holding until 12-MAR-1992 12:00
sodom$ @x 672
UIC = "[ALLIN1]"
NAME = "ALLIN1"
sodom$ set comm oa$lib:a1submit
sodom$ a1submit oa$lib:sm_restart /after=12:00:00/user=allin1
Job SM_RESTART (queue SYS$BATCH, entry 673) holding until 12-MAR-1992 12:00
sodom$ @x 673
UIC = "[TALLETT]"
NAME = "ALLIN1"
so my poor programmer friend is correct! I never even knew this
UIC existed! By the way, it appears to have changed on V5.5. There
A1SUBMIT seems to work like SUBMIT.
Regards,
Paul
|
| 192.13 | OA$SUBMIT privs | SAC::JOYCE | Leaving... and I don't give a XXXX | Thu Jun 04 1992 10:46 | 12 |
|
A related question (I think)...
The Security Police of one of our major customers are asking why the
OA$SUBMIT image requires CMKRNL and SYSPRV. The documentation only
mentions CMKRNL. They want to know if SYSPRV is really needed and, if
so, EXACTLY why (and if so, why ain't it in the documentation?).
Thanks in advance.
Andy
|
| 192.14 | To write to queues... | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Jun 04 1992 11:02 | 13 |
| It got SYSPRV added to it in V3.0 so that we could be sure of always
being able to write jobs onto the selected queue. I assume we must have
had a problem report complaining about that.
I wasn't aware that we normally listed all the privilege justifications
in the doc. set, although we do justify them to the SQM police
internally, before the product ships. I've posted the list of
justifications in this (or previous versions of) notesfile in the past.
Graham
PS But hey, if you've got CMKRNL, You can easily get SYSPRV or anything
else. Perhaps we shouldn't tell customers that....
|
| 192.15 | For the Administrator | UTRTSC::SCHOLLAERT | Sweden, here we come | Thu Jun 04 1992 11:14 | 19 |
| re.13
SYSPRV was intruduced in 2.4. Looks like documantation was not
updated.
From the STARS:
For the Administrator to be successful in cancelling housekeeping
procedures they would need the SYSPRV privilege.
Obviously this is not suitable to many installations, A1SUBMIT was
designed to solve problems such as this and needs to be installed
with SYSPRV privilege by the ALL-IN-1 startup procedure.
This problem has been fixed in ALL-IN-1 V2.4.
Regards,
Jan
|