home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.security.misc:822 alt.security:4014 comp.unix.ultrix:5901
- Path: sparky!uunet!mcsun!uknet!ox-prg!nnhost!pcl
- From: pcl@oxford.ac.uk (Paul Leyland)
- Newsgroups: comp.security.misc,alt.security,comp.unix.ultrix
- Subject: Problem with npasswd??
- Message-ID: <PCL.92Jul27140810@black.oxford.ac.uk>
- Date: 27 Jul 92 13:08:10 GMT
- Sender: news@comlab.ox.ac.uk
- Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
- 6NN
- Lines: 39
-
-
- Some while ago, I ported Clyde Hoover's npasswd program to Ultrix
- ENHANCED security. A few people have been beta testing it since then.
-
- At our site, I *may* have found a problem, though I have no idea
- whether I broke the Ultrix specific code, or if it is a bug in the
- generic code. This under Ultrix v4.2a
-
- Third-party password changes sometimes change *root's* password. That
- is, suppose I (pcl) am approached by jruser to change their password.
- I type something like:
- % \/bin/su - root
- Password:
- # npasswd jruser
- ...
-
- If I make a typo at this point, and have to have another go at
- changing jruser's password (still in the same invocation of npasswd,
- BTW) and succeed in getting a password through, I *sometimes* find
- that root's password has been changed and the user's has not. My
- password is left unchanged. (Phew!)
-
- As a work round, I always ensure I get it right first time, or ^C out
- on first error.
-
- I am unable to make it fail solidly. I have never been able to make
- it fail running under dbx, where I can monitor what is going on.
-
-
- Does anyone have any ideas? As you might guess, I'm keen to clear
- this up quickly.
-
- Paul
-
- --
- Paul Leyland <pcl@oxford.ac.uk> | Hanging on in quiet desperation is
- Oxford University Computing Service | the English way.
- 13 Banbury Road, Oxford, OX2 6NN, UK | The time is come, the song is over.
- Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say.
-