home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / vmsnet / internal / 1427 < prev    next >
Encoding:
Internet Message Format  |  1992-10-09  |  2.0 KB

  1. Path: sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!gatech!rpi!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
  2. From: Chris Petroff <CHRIS@aardvark.ucs.uoknor.edu>
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: Finding a users disk name
  5. Message-ID: <8564176@MVB.SAIC.COM>
  6. Date: Fri, 9 Oct 92 10:05 CDT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 34
  10.  
  11. > Hello, I'm helping a friend of mine write a program that kinda simulates
  12. > a unix-type operating system. What we are having trouble with is the
  13. > cd ~user  command. We don't know how to get the person's disk area name
  14. > from their username. We'd like to be able to do cd ~user and have the
  15. > program give us back disk$xxx:[user]. Is there an easy way to do this,
  16. > and a way to do it without having operator privileges. Oh, we are using
  17. > VMS version 5.5
  18.  
  19. What we do here for nonpriv access to low-level SYSUAF info is use the
  20. LIST command from AUTHORIZE to gererate a file with basic info, and then
  21. place it in a world readable spot with appropriate access privs so that
  22. anyone can use it.  A simple SEARCH on this file will return not only
  23. the home directory/device of a user, but also his UIC, Personal Name,
  24. privs (NORMAL/ALL), base priority and Account name.  After we make the
  25. SYSUAF.LIS file, we strip out some stuff and leave only the username,
  26. owner/personal name, UIC, and Directory.  We have a command file which
  27. does this for us which we run after adding/deleting accounts.  We also
  28. have several utilities which are driven off this file...
  29.  
  30. This allows nonprivilaged access to the info, but the real benifit at
  31. the time it was implimented (on a 11/780) was that we did not keep
  32. trashing SUSUAF.DAT everytime we wanted to look someone up!  On a
  33. 6320 (what we have now) it's still more efficient but probably not so
  34. big a deal....
  35.  
  36. This may seem like a bothersome way of doing it, but it is VERY simple
  37. and easy to maintain.  Also, it is not likely to break with the next
  38. version of VMS, but if it does, it is real simple to fix!
  39.  
  40. Just my $.02
  41.  
  42. :-)
  43.  
  44. Chris
  45.