| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 679.1 | OA$ADMIN makes the difference | BUFFER::VICKERS | Rearranging the DEChairs | Wed May 13 1992 00:38 | 27 |
| Joan,
Almost certainly, the reason that you were able to change the profile
records even with no privileges is that you have the OA$ADMIN
identifier. Only accounts with OA$ADMIN are allowed to change profile
records which they do not own.
I am not aware of any way around this particular part of the ALL-IN-1
security system.
It sounds like the users on the system are sufficiently otherwise
engaged that giving their VMS UAF records the OA$ADMIN privilege
shouldn't be THAT risky. If they don't have the ADMIN forms library
they won't be able to get to the UI of the administrator subsystem.
A sufficiently computer and system knowledgeable person could use
OA$ADMIN to submit batch jobs that could do some harm.
You certainly could try granting the OA$ADMIN identifier to one of the
user accounts and verify that the 'joint' can be rolled that way. You
then have the security issues to ponder. Hopefully, someone can give
you some pointers that may be less risky.
I assume that these 'joints' are the safe kind. Safe meaning that they
are in Great Britain and not inhaled? That's Bill Clinton 'humour'.
Keep smiling,
don
|
| 679.2 | A Quick play with ACLs? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed May 13 1992 08:50 | 19 |
| The profile can be updated if the updating process has *DEFAULT* access
to the profile file. As Don says, there's also a special check for
Administrators, although I can't remember whether it's based on the
Admin flsag in the profile, or having the ACL.
It's possible that you may just be able to give people the Admin flag
and not the ACL, causing the image to raise provs to access it. But
maybe not. Even if this worked, you'd then get the problem that seeing
the Admin flag at initialisation time, we'd try to open the SYSTEM.PST
for writer, but fail, since the user wouldn't have the ACL to get to
it.
Perhaps you could just put some write ACLs on the profile, which you
just grant to these JT users?
Graham
PS In Britain, "joint" still has the meaning of what one of my college
friends used to call "naughty ciggies"....
|
| 679.3 | 2.4 Upgrade could be the problem?? | LARVAE::COLLINS_J | | Wed May 13 1992 09:54 | 29 |
| >Almost certainly, the reason that you were able to change the profile
>records even with no privileges is that you have the OA$ADMIN
>identifier.
I did have the OA$ADMIN id originally, but I removed it from my UA
along with other all other privileges. My account 'looked' exactly
the same as the user's account I was testing.
>The profile can be updated if the updating process has *DEFAULT*
>access to the profile file.
Sorry to be a pain, but could you explain the above - I'm still
fairly new to ALL-IN-1 and as I'm begining to find out - there's a lot
to learn and understand!
One thing I forgot to mention in all this, these users were able to
update their profile prior to 2.4 upgrade that took place recently!
I'm going to attempt to speak to user, log into his account and put a
trace on then do the same on my own account and check the differences of
both. If this doesn't show anything, then I'll do the same from an
account on the other cluster (This cluster isn't presenting the same
problem and in theory they're now supposed to be the same "COMMON
SYSTEM" In practice however....well I'm not so sure...) anyway I will
let you know the outcome of my findings!!
Thanks & regards
Joan
|
| 679.4 | A slightly fuller story :-) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed May 13 1992 10:59 | 38 |
| Joan,
I didn't realise that you were "new on the block" or I would have
explained it in more detail.
The Profile file is protected against write by anyone other than
system, so that people can't hack into it to give themselves ALL-IN-1
privs they shouldn't have. Unfortunately, this means that you can't
update those fields in the profile that you aresupposed to have access
to, like mail status etc. So when you try to write to the profile, the
code turns on its image SYSPRV to write to the file, assuming a certin
set of checks have passed...
First call the VMS System service $CHECK_ACCESS to see if the user has
write access to the OA$DATA:PROFILE.DAT file. Now you might want to
look up the description of this in the books, but basically one of its
"features" is that it is intended to be used to establish if some other
user could access a file, so it decided if the access is permitted
based on what their *default* privs and identifiers are in AUTHORIZE,
rather than anything that might be currently turned on. So having
SETPRV as an authorized prov doesn't help, since the system service
doesn't see that as enabling you to turn on SYSPRV (or BYPASS!!) to get
to the file.
Then, if the admin flag is set in the profile (NB *NOT* the posession
of the OA$ADMIN ACL) then privs are turned on to write to the file, so
it doesn't matter how it's protected or what other privs you have.
Next check whether it's our own record we're trying to change, don't
allow other records to be changed.
Finally the code checks if the field is one of the fields in the
PROFILe form, which is the set that unprivileged users are allowed to
change. If so, turn on image privs and go ahead.
Hope that helps,
Graham
|