07-24-2011
Quote:
Originally Posted by
jlliagre
Your file system looks seriously broken. With such a /etc/password file, you'll have a hard time booting, login in or whatever.
Dude, Thanks for your reply...However I am able to login through my normal users as root and sysdba etc...I haven't tried logging in as eschhen as I dont have password from it..Moreover I cant even delete the user..As it shows no such user exists....Please advice if a FS restore from a tape backup can resolve the issue?..or a reboot will also serve my cause?
10 More Discussions You Might Find Interesting
1. UNIX for Dummies Questions & Answers
Hi All
Here is a the enty for my user on a UNIX from the /etc/passwd file, i want to know what each field denotes where can i get to know it?
kankipas:!:275:1:Swaraj Kankipati - Brea PTX Support:/home/kankipas:/usr/bin/ksh
If anyone could tell me that would be great
Thanks
Swaraj (5 Replies)
Discussion started by: kswaraj
5 Replies
2. Cybersecurity
hi
Does anyone anyone know what the last line of a unix user passwd file signifes?
Mine shows "+:::::"
best (4 Replies)
Discussion started by: s_mad010
4 Replies
3. Shell Programming and Scripting
Hi all,
As all of us know that in /etc/passwd file the first field correspond to username
could any one tell me what is bin , damoen etc in the first field, and r they in
user field , what is nologin in the last column ?
root:x:0:0:root:/root:/bin/bash ... (4 Replies)
Discussion started by: useless79
4 Replies
4. Solaris
I have a question here on /etc/passwd file.
There is a user called user_a, when it is defined in /etc/passwd as below
+user_a:x:::::/bin/ksh
after user_a login, the system could not recognize the correct enviromental variable $USER_A_HOME which is defined in .kshrc file (under /home/user_a... (2 Replies)
Discussion started by: ij_2005
2 Replies
5. Solaris
Hi all,
I am bit confused about UIDs on my server where LDAP athentication happens. UIDs are generally in the range of 0-65534 for any Solaris OS version(correct if i am wrong). My server is running on Solaris 9. Below are user accounts available on my server.
... (10 Replies)
Discussion started by: vvpotugunta
10 Replies
6. Red Hat
First post, sorry to be a bother but this one has been dogging me. I have a process user (java application server) that trips a resource limit every couple weeks and need help finding what limit we're hitting.
First, this is what's running:
This is the error when jobs are run or the... (0 Replies)
Discussion started by: Katahdin
0 Replies
7. Solaris
Hi Folks,
I have Solaris 10, latest release.
We have passwd aging set in /etc/defalut/passwd.
I have an account that passwd should never expire. Acheived by emptying associated users shadow file entries for passwd aging.
When I reset the users passwd using passwd command, it re enables... (3 Replies)
Discussion started by: BG_JrAdmin
3 Replies
8. AIX
Hello All,
Can anyone post the default /etc/passwd file for AIX?
I would like to compare with an existing machine of mine and want to identify what are the default users that are created when the O/S is installed.
In other words I would like to see the system users in AIX. Not the ones created... (1 Reply)
Discussion started by: lovesaikrishna
1 Replies
9. UNIX for Dummies Questions & Answers
Not an unix expert, I read a few pages on the web about passwd files, but I didn't find the answers I need about the last 8 lines of the passwd file I'm taking a look at.
I'm assuming their shortcuts to another file that may have the actual usernames of users on the system.
Please, any help... (1 Reply)
Discussion started by: fusion31
1 Replies
10. AIX
Does anyone know when AIX started using /etc/security/passwd instead of /etc/passwd to store encrypted passwords? (1 Reply)
Discussion started by: Anne Neville
1 Replies
GETPWENT(3) Library Functions Manual GETPWENT(3)
NAME
getpwent, getpwnam, getpwuid, setpassent, setpwfile, setpwent, endpwent - get password file entries
SYNOPSIS
#include <sys/types.h>
#include <pwd.h>
struct passwd *getpwent()
struct passwd *getpwnam(login)
char *login;
struct passwd *getpwuid(uid)
uid_t uid;
int setpassent(stayopen)
int stayopen;
void setpwfile(file)
char *file;
int setpwent()
void endpwent()
DESCRIPTION
Getpwent, getpwuid, and getpwnam each return a pointer to a structure containing the broken-out fields of a line in the password file.
This structure is defined by the include file <pwd.h>, and contains the following fields:
struct passwd {
char *pw_name; /* user name */
char *pw_passwd; /* encrypted password */
uid_t pw_uid; /* user uid */
gid_t pw_gid; /* user gid */
time_t pw_change; /* password change time */
char *pw_class; /* user access class */
char *pw_gecos; /* Honeywell login info */
char *pw_dir; /* home directory */
char *pw_shell; /* default shell */
time_t pw_expire; /* account expiration */
};
These fields are more completely described in passwd(5).
Getpwnam and getpwuid search the password database for a matching user name or user uid, respectively, returning the first one encountered.
Identical user names or user uids may result in undefined behavior.
Getpwent sequentially reads the password database and is intended for programs that wish to step through the complete list of users.
All three routines will open the password file for reading, if necessary.
Setpwfile changes the default password file to file, thus allowing the use of alternate password files.
Setpassent opens the file or rewinds it if it is already open. If stayopen is non-zero, file descriptors are left open, significantly
speeding up subsequent calls. This functionality is unnecessary for getpwent as it doesn't close its file descriptors by default. It
should also be noted that it is dangerous for long-running programs to use this functionality as the password file may be updated by
chpass(1), passwd(1), or vipw(8).
Setpwent is identical to setpassent with an argument of zero.
Endpwent closes any open files.
These routines have been written to ``shadow'' the password file, e.g. allow only certain programs to have access to the encrypted pass-
word. This is done by using the mkpasswd(8) program, which creates ndbm(3) databases that correspond to the password file, with the single
exception that, rather than storing the encrypted password in the database, it stores the offset in the password file where the encrypted
password may be found. Getpwent, getpwnam, and getpwuid will use the ndbm files in preference to the ``real'' password files, only reading
the password file itself, to obtain the encrypted password, if the process is running with an effective user id equivalent to super-user.
If the password file itself is protected, and the ndbm files are not, this makes the password available only to programs running with
super-user privileges.
FILES
/etc/passwd
SEE ALSO
getlogin(3), getgrent(3), ndbm(3), passwd(5)
DIAGNOSTICS
The routines getpwent, getpwnam, and getpwuid, return a null pointer on EOF or error. Setpassent and setpwent return 0 on failure and 1 on
success. Endpwent and setpwfile have no return value.
BUGS
All information is contained in a static buffer which is overwritten by each new call. It must be copied elsewhere to be retained.
Intermixing calls to getpwent with calls to getpwnam or getpwuid, or intermixing calls to getpwnam and getpwuid, after using setpassent to
require that file descriptors be left open, may result in undefined behavior.
The routines getpwent, endpwent, setpassent, and setpwent are fairly useless in a networked environment and should be avoided, if possible.
7th Edition February 23, 1989 GETPWENT(3)