Conference vaxaxp::vmsnotes

    Turn on SYSPRV (if not already enabled).  Read the target UAF entry.
    Turn off SYSPRV (if it was enabled).  Perform the comparision.  Zero
    out any security-relevent information in the buffer(s) you read in,
    as appropriate.

    While your technique will likely work, it will generate spurious audits
    on the failures.  (And security failure audits against SYSUAF might
    cause some concern among system and/or security managers...  With the
    use of SYSPRV, you will potentially get a use-of-privilege audit, and
    no access failure audits.)

re .0
    
>can I rely on the error values I get above to determine whether the user is
>in my group?
    
    Well the system service doco purports to document this behaviour so
    perhaps you could make an argument that you can rely on it but I
    wouldn't, not least because as you imply the behaviour violates good
    security practice and therefore someone sufficiently paranoid might
    change it in the future.

> I want to find out if a user is in my group. 

  Assuming the account has an associated identifier the same as the username,
  you can determine the UIC using $ASCTOID (or F$IDENTIFIER from DCL). From
  there, you can find the group number.

  This won't require any privilege or trigger audit alarms.

>Is the above a weakening in security (because I don't need privileges to find 
>out if someone is in my group)

  I wouldn't have thought that a users UIC value was something that needed
  to be protected, especially from members of their own group Your test only
  allows you to say if they're in your group, it does not reveal the UIC.
  Consider that the above will work on most usernames without privilege and
  reveal UIC.

  What the explicit error messages *does* do is make it much easier to
  diagnose a fault. The alleged "increase" insecurity by deliberately
  obscuring error messages is massively outweighed by the person-*EONS*
  wasted trying to figure out the problem causing a cursed "NOPRIV" or
 "EXQUOTA" message.  
						John Gillings, Sydney CSC

.3:> I want to find out if a user is in my group. 
.3:
.3:  Assuming the account has an associated identifier the same as the username,
.3:  you can determine the UIC using $ASCTOID (or F$IDENTIFIER from DCL). From
.3:  there, you can find the group number.
.3:
.3:  This won't require any privilege or trigger audit alarms.

   I'd not bet on this one.  There are sites that do not have matching
   identifiers, and there are sites that have no identifiers.  (And there
   are identifiers -- such as "SYSTEM" -- that can be "messed up" on most
   OpenVMS systems.)
    
.2:>can I rely on the error values I get above to determine whether the user is
.2:>in my group?
.2:    
.2:    Well the system service doco purports to document this behaviour so
.2:    perhaps you could make an argument that you can rely on it but I
.2:    wouldn't, not least because as you imply the behaviour violates good
.2:    security practice and therefore someone sufficiently paranoid might
.2:    change it in the future.

   It occurs to me that if the image doesn't correctly and carefully
   maintain the active privilege mask, one would see some interesting
   behaviour if the application happened to run with privileges enabled
   for some reason...  (This depending-on-the-privilege-error behaviour
   looks like it might become more work than it's worth.)

    re .3
    
    Does /ATTR=NAME_HIDDEN work for UIC valued identifiers?
    Does it work at all?
    
>  wasted trying to figure out the problem causing a cursed "NOPRIV" or
> "EXQUOTA" message.  
    
    Agreed that NOSYSPRV is better than NOPRIV.