Bug 65577 - useradd: unable to open password file
Summary: useradd: unable to open password file
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils   
(Show other bugs)
Version: 7.3
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-05-27 21:07 UTC by Joe Acosta
Modified: 2007-03-27 03:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-18 16:59:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Joe Acosta 2002-05-27 21:07:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510

Description of problem:
as root

root# useradd -u 95 -g named -d /var/named -s /bin/false -n named
useradd: unable to open password file



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
both user add and adduser do the same thing as well as userconf

1. as root adda group
2. then execute
useradd -u 95 -g named -d /var/named -s /bin/false -n named
2. reply is 
useradd: unable to open password file


	

Actual Results:  is seems that this file is locked somehow after adding a goup.
will reboot to see if that unlocks the file

Additional info:

Comment 1 Warren Togami 2002-06-03 21:36:42 UTC
Someone else reported in Bug 65505 that his passwd (or related files) has been
somehow corrupted, causing redhat-config-users to crash.  Does this cause
permanent corruption in /etc/passwd (even after reboot)?


Comment 2 Joe Acosta 2002-06-04 01:02:54 UTC
It is still 'locked' after a reboot.  

This affects useradd, adduser, redhat-usrs-conf, and any programs that seems to
change the /etc/passwd that I have tried.  (not sure what else)

I'd edit the file manually but not sure how to regenerate the /etc/shadow after
changing the password file.  I know on Sun I have to do that.

Comment 3 Joe Acosta 2002-10-24 03:16:07 UTC
This also affects vipw as well.  

vipw: can't unlock /etc/passwd: Operation not permitted (your changes are still
in /etc/ptmp)


then trying to execute vipw again
root># vipw 
vipw: the password file is busy (/etc/ptmp present)

Comment 4 Joe Acosta 2002-10-24 17:53:50 UTC
This needs to be escalated.  As it turns out I cannot add users to the system
with the state that this is in.  I have other boxes that I am supposed to upgrade.  

I cannot rm -f /etc/passwd
I cannot edit it with vi, I cannot copy a file over it even in single user mode
(init 1) as root with the drives mouted rw, evern after multiple reboots.

I would seriously like to know what is going on with this.  I don't understand
why this is locked.  I have deleted the /etc/ptmp file as well as the
/etc/.pwd.lock file, yet even using vi or echo <data> >> /etc/passwd will not
work as root.  I have never seen an issue like this on ANY unix system and if
this cannot be resolved soon,  I will have to rebuild the system eithe rwith 7.2
or some other distro where this does not exist.

Comment 5 Alan Cox 2002-12-18 16:59:19 UTC
We've never been able to recreate this. It appears that since things like cat
fail you got something like a hardware fault (eg that block on the disk being
bad) or that someone malicious cracked your box and set the password file
immutable with chattr



Note You need to log in before you can comment on or make changes to this bug.