home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.aix
- Path: sparky!uunet!gatech!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!lwvanels
- From: lwvanels@athena.mit.edu (Lucien W. Van Elsen)
- Subject: Re: problem with putuserpw subroutine
- In-Reply-To: bware@slate.mines.colorado.edu's message of 23 Jul 92 22:57:34 GMT
- Message-ID: <LWVANELS.92Jul27094958@fionavar.mit.edu>
- Sender: news@athena.mit.edu (News system)
- Nntp-Posting-Host: fionavar.mit.edu
- Reply-To: lwvanels@MIT.EDU
- Organization: Massachusetts Institute of Technology
- References: <1992Jul23.225734.9999@slate.mines.colorado.edu>
- Date: Mon, 27 Jul 1992 13:50:16 GMT
- Lines: 23
-
- bware@slate.mines.colorado.edu (Bob Ware) writes:
-
- > Has anyone had success using the putuserpw subroutine?
- > The getuserpw subroutine seems to work as advertised, but the putuserpw
- > routine always bombs with errno pointing to:
- > Only the owner or a privileged user can perform the operation.
-
- It looks like there is indeed a bug; it looks like getuserpw() is doing a
- setpwdb() to get read-only access to the auth db, and never closing it when
- it is finished. Furthermore, it looks like putuserpw is trying to be smart
- about things, and not trying to get read-write access if the database is
- open at all. Since getuserpw left it open with read-only access, putuserpw
- fails.
-
- There's two work-arounds for this- either explicitly call
- setpwdb(S_READ|S_WRITE) before putuserpw(), or call endpwdb() after the call
- to getuserpw.
-
- -Lucien
-
- ----------------------------------------------------------------------------
- Lucien Van Elsen | lwvanels@athena.mit.edu
- MIT Athena Systems Development |
-