/etc/passwd.pacnew

From today's update of the filesystem package, I noted this difference between /etc/passwd:
ftp:x:14:11:ftp:/home/ftp:/bin/false
and /etc/passwd.pacnew:
ftp:x:14:11:ftp:/srv/ftp:/bin/false
What does it mean? Have I to make the change in my /etc/passwd?

http://archlinux.org/pipermail/arch-dev … 06959.html

Similar Messages

How to handle home directory change in /etc/passwd.pacnew?

Hey,
the recent update of the filesystem package had a change in /etc/passwd that
I am not sure how to handle:
daemon:x:2:2:daemon:/sbin:/usr/bin/nologin
was changed to
daemon:x:2:2:daemon:/:/usr/bin/nologin
As you can see, the home directory of daemon was changed from /sbin to /.
Should I merge that change into my /etc/passwd?

I have read that thread but I am not quite sure that it applies to
this situation.
Leonid.I basically says that
[...] if your group/passwd files are functional before the update -- keep them as is
(unless you wan to do cosmetic changes)
Now, adding info to the GECOS field or substituting /sbin with /usr/bin
doesn't really alter the behaviour of the system, but changing a user's
home directory seems a little bit more fundamental to me.

/etc/group and /etc/passwd corrupted

My /etc/group and /etc/passwd (and possibly others) are corrupted (my silly error handling pacnew files). I tried restoring the backups (group- and similar) and also ran grpconv, pwdconv,, pwck without fixing things. I've edited the files, using those in another machine as a template but no luck.
Various commands (e.g. ssh) fail with the message:
No user exists for uid 1000
Before I give up and reinstall, is there any way I can restore things to how they should be?

Thanks for replies. I can't recreate my user because it's already there. I can log in as ac without difficulty and do most things - just a few (mportant) fail.
I don't understand why it keeps saying the user ac is uid 1000. After reading the wikis I think my /etc/group and /etc/passwd are correct. /etc/passwd has:
ac:x:1000:100::/home/ac:/bin/bash
and /etc/group has:
users:x:100:ac
ac:x:100:ac
I'm not sure the last line should be there, but removing it doesn't help. The entries on a second machine are similar.
I'll sleep on it to see if I think of something else to try in the morning, otherwise I'll have to reinstall tomorrow.

[SOLVED] Today's update of /etc/group, /etc/passwd and /etc/gshadow

Hello,
During the regular updates I received an update of /etc/groups. I wonder what I should do here, as there are some differences between the old file and the pacnew one. I suppose that when I use the command to add my user to a group, it gets written into this file. So, just recklessly moving the pacnew file in the place of the old one, will mess up all my groups, won't it?
Then what should I do? All the entries in the pacnew file are also present in the old one, so I guess I could just delete the pacnew one and keep the old one. Am I right?
EDIT: The same goes to /etc/passwd and /etc/gshadow.
Last edited by Unia (2012-10-06 09:51:23)

teateawhy wrote:
If you had the uuid user before like me the uuid line in your own files is different from the pacnew file. You have to delete the uuid line near the bottom in your old file. Then insert the new uuid entry including the new number in the place near the top suggested by the pacnew file. Keep the other lines untouched, then save your changes and delete the pacnew files.
Edit: On a system that has actually been modified from a default install the new files will for sure be different to the old ones.
Thanks, teateawhy! I currently have this listed in /etc/passwd:
uuidd:x:998:998::/:/sbin/nologin
And this is in the .pacnew file:
uuidd:x:68:68:uuidd:/:/sbin/nologin
So, I can just copy the entry from the .pacnew file, overwriting the old entry, right?
What I don't understand is how the two numbers 998 representing the UID and GID can suddenly change to 68. Shouldn't they have to correspond with some other reference or list of users/groups...?
I'm sure it's fine to just replace the entry as you suggested, but I wondered if there was a way to double-check which uid/gid should be used? It's not that I don't trust you, but I don't fully understand how these group/passwd files work and I'm trying to get my head round it all.
Cheers,
esuhl

Systemd entries in /etc/passwd and others...

Hi! How do I find out what are correct entries for systemd in /etc/passwd, /etc/group, /etc/shadow and others in current system? What if I screw them up during system update and maybe lose some of them or will end up having those unneeded?...

I don't understand what you want. A backup maybe? Do you have any pacnew files?

[SOLVED] /etc/passwd and /etc/shadow -- pwck shows missing groups

I recently found out about the pwck and grpck commands to check for errors/inconsistencies in the passwd, group, shadow and gshadow files... grpck returns no errors, but pwck returns this:
user 'avahi': no group 84
user 'postgres': no group 88
user 'ntp': no group 87
pwck: no changes
These are the relevant lines from /etc/passwd:
avahi:x:84:84:Avahi daemon:/:/bin/false
postgres:x:88:88:PostgreSQL user:/var/lib/postgres:/bin/bash
ntp:x:87:87:Network Time Protocol:/var/lib/ntp:/bin/false
There are lines for those users in /etc/shadow... but... I'm not sure what I need to do to fix the problem.
I think I understand enough, now, to maintain the files in future, but would anyone know I can fix this?
Last edited by esuhl (2012-10-08 20:22:05)

2ManyDogs wrote:I don't know how to fix the errors, but I'm really curious about why you decided to run those commands. Were you having a problem you thought might be ralated to groups and/or passwords? What are groups 84, 97, and 88?
Ha! Well... when I started using Arch I really didn't know much about Linux and I an update providing some .pacnew files (/etc/group, gshadow, passwd, shadow) and... well... I don't know what I did, but I think it was probably not what I should have done(!). I used grpck in the past and got no errors and it suddenly occurred to me today that there should be an equivalent for checking /etc/passwd... so that's why I just ran the commands now. Everything seems to be working, however...
I don't have an entry for groups 84, 87 and 88 in my /etc/group file... Hmmm...
I tried running this command to find any files associated with that group, but only get the following:
[root@i7pc tim]# find / -gid 88
find: `/run/user/1000/gvfs': Permission denied
find: `/proc/1806/task/1806/fd/5': No such file or directory
find: `/proc/1806/task/1806/fdinfo/5': No such file or directory
find: `/proc/1806/fd/5': No such file or directory
find: `/proc/1806/fdinfo/5': No such file or directory
I get similar output for the other groups, so... can I just delete them from /etc/passwd and /etc/shadow?
I notice I have the avahi package installed, however, and group 84 relates to user 'avahi'... so... surely I need the avahi user...?
Last edited by esuhl (2012-10-07 23:09:30)

New /etc/passwd.shadow

I have seen that with an upgrade I have an /etc/shadow.pacnew From what I know it is only a shadow copy of /etc/passwd without the password and can simply be generated by pwconv (similarly /etc/group.shadow can be generated by grpconv). So my question is why archlinux proposes me /etc/shadow.pacnew? What I did is simply fix the new /etc/passwd that were also proposed, rm the /etc/shadow.pacnew and run pwconv. If this is really the good thing to do, /etc/shadow.pacnew shouldn't have been proposed.

olive wrote:I think most of you do not understand my point. I do not understand why /etc/shadow has to be shipped in the first place. It would be best to just ship /etc/passwd and to generate /etc/shadow automatically by pwconv. There are a lot of such files that can be automatically generated and such files are in general not included in the package.
I ran pwconv and now I have two entries for dbus in /etc/shadow:
I manually megerd the shadow.pacnew and had en entry for dbus
dbus:x:14871::::::
after running pwconv I have two entries for dbus:
dbus:x:14871::::::
and
dbus:x:15686:0:99999:7:::
I assume there arnt ment to be two?
*EDIT
Seems either works? I dont get any problems either way (I dont think)
But, I think that:
dbus:x:15686:0:99999:7:::
was the original entry for dbus before the pacnew anyway?
Last edited by jrussell (2012-12-12 00:33:27)

System.getProperty("user.name") not working without /etc/passwd, CentOS 4.3

Dear all,
I'm having trouble getting the system property user.name (which we need in our ant scripts) on our CentOS box. :(
When running the program below thru
java dumpproperties2
it prints "user.name='?'" on our CentOS 4.3. On win32 it works. It turns out that if you add the account corresponding to the EUID to /etc/passwd it works correctly. However, we don't use passwd authentication but an enterprise wide LDAP-system. Our /etc/nsswitch.conf says:
passwd: files ldap
One work around is to replace the java executable with a script that does
/path/to/jdk/bin/java -Duser.name=$USER -Duser.home=$HOME $@
Used jdk is j2se 1.5.0_13 Linux 32-bit.
Some questions for the experts:
1) Is there any other way?
2) Is it a known issue that Linux versions of the jdk just looks in /etc/passwd to map uid to user name (and home dir) instead of doing what the rest of the system, like whoami, does? I haven't found anything in either the readme or installation instructions, nor in the bug db.
Br, Jesper Tr�g�rdh
public class dumpproperties2 {
    public static void main(String[] args) {
     String s = System.getProperty("user.name");
     System.out.println("user.name='" + s + "'");
}

Does this work?
//public final class System
public static String getenv(String name)Then you can access the USER environment from inside Java.

Smc and smuser both put wrong home directory in /etc/passwd

Hello,
I'm trying to use 'smuser add' as an alternative to 'useradd' in a setuid script, using -d to specify a home directory other than the default. Unfortunately, although the directory is created in the right place, the default is written into /etc/passwd.
%smuser add -u sapadm -p ***** -- -d /appuser/inputs/tom -g sapusers -n tom -s /bin/sh
Loading Tool: com.sun.admin.usermgr.cli.user.UserMgrCli from localhost
Login to localhost as user sapadm was successful.
Download of com.sun.admin.usermgr.cli.user.UserMgrCli from localhost was successful.
% ls -al /appuser/inputs/tom
total 14
drwxr-x--- 2 tom sapusers 5 Mar 28 15:48 .
drwxr-xr-x 3 sj staff 3 Mar 28 15:48 ..
-rw-r--r-- 1 tom sapusers 136 Mar 28 15:48 .cshrc
-rw-r--r-- 1 tom sapusers 157 Mar 28 15:48 .login
-rw-r--r-- 1 tom sapusers 174 Mar 28 15:48 .profile
% cat /etc/passwd
tom:x:101:1002::/home/tom:/bin/sh
% ls -al /home/tom
/home/tom: No such file or directory
% uname -a
SunOS sun03 5.10 Generic_127112-07 i86pc i386 i86pc
Exactly the same thing happens when I use the SMC2.1 GUI - even though it echoes back to me that the directory path qill /appuser/inputs before I hit 'finish', the directory is created correctly, but /home/tom goes into /etc/passwd.
Is there any fix/workaround for this, or am I back to an old-fashioned useradd in a setuid script?
Thanks
-- Steve

Father wrote:
that way, they are chrooted into an empty directory and have no files they can tamper with
isnt that a little dangerous??
What files a user can change is determined by the files' permission settings, not by the user's homedir. The homedir only tells what the initial working directory when a user logs in is, nothing else, it doesn't implicit writing or even reading access. So no, it's not dangerous, not even a little.

Why i can not find my login name in /etc/passwd?

why i can not find my login name in /etc/passwd?
Thank you~

I want to ask the same question as steve359, where the multi-user accounts information stored?
I saw mysql user in passwd, do you have any idea on what purpose of mac os ultilize mysql ?
Thanks!

[SOLVED] Not sure what to do with passwd.pacnew

Hey, I have just encountered my first .pacnew file and am not sure what to do with it. I have read the wiki, but I know a lot of this has to be left up to the user, and I don't think I'm educated enough on this to solve it on my own. The passwd file looks like this:
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
ftp:x:14:11:ftp:/srv/ftp:/bin/false
http:x:33:33:http:/srv/http:/bin/false
uuidd:x:68:68:uuidd:/:/sbin/nologin
dbus:x:81:81:dbus:/:/sbin/nologin
nobody:x:99:99:nobody:/:/bin/false
polkitd:x:102:102:Policy Kit Daemon:/:/bin/false
avahi:x:84:84:avahi:/:/bin/false
mysql:x:89:89::/var/lib/mysql:/bin/false
kdm:x:135:135::/var/lib/kdm:/bin/false
johnathan:x:1000:100::/home/johnathan:/bin/bash
git:x:999:999:git daemon user:/:/bin/bash
systemd-journal-gateway:x:191:191::/:/usr/bin/nologin
systemd-timesync:x:192:192::/:/usr/bin/nologin
and the passwd.pacnew file looks like this:
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
ftp:x:14:11:ftp:/srv/ftp:/bin/false
http:x:33:33:http:/srv/http:/bin/false
uuidd:x:68:68:uuidd:/:/sbin/nologin
dbus:x:81:81:dbus:/:/sbin/nologin
nobody:x:99:99:nobody:/:/bin/false
systemd-journal-gateway:x:191:191:systemd-journal-gateway:/:/bin/false
systemd-timesync:x:192:192:systemd-timesync:/:/bin/false
As you can see, there are quite different, including missing lines in the .pacnew file and a change from polkitd and avahi to systemd. Could anyone tell me what is safe to merge?
Thanks for your help!
Last edited by SteampunkWhooves (2014-05-29 22:28:40)

jasonwryan wrote:
There is a change in the .pacnew...
systemd-journal-gateway:x:191:191:systemd-journal-gateway:/:/bin/false
systemd-timesync:x:192:192:systemd-timesync:/:/bin/false
You should use vimdiff, or a similar tool, to identify any updates to the files that you may want to pull into your current config.
I think such changes should also be announced on Arch News / RSS
i.e. https://www.archlinux.org/news/
So that users know that there are lines to be imported. (Atleast for filesystem package if not other packages)
EDIT:
I notice that those two users are already there in my system (in both passwd and shadow). So somewhere update already added those users. That is why possibly there was no announcement on Arch News.
But those new users are NOT in *new* shadow. IS IT A BUG? i.e. if users are in passwd, they should in shadow as well right?
Last edited by amish (2014-06-07 06:16:52)

Login Process & Security of /etc/passwd and /etc/shadow

Guys,
I have few questions, Please help me out.
1. What is the Solaris 8 and Solaris 9 environment's boot files ?
2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?
3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.
Help me understand these concepts.
Thank you.
Arut

Sounds like you're very new to Solaris:
1. What is the Solaris 8 and Solaris 9 environment's boot files ?/kernel/genunix is the primary boot file. The directory structure in /kernel is also boot related. /usr/kernel is also boot related.
2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?Generally three files are related: /etc/passwd, /etc/shadow, and the program /bin/login. Some applications will process /etc/passwd and /etc/shadow on their own and bypass /bin/login - but for you're purposes this is a good general answer.
As a minor example (and if I remember correctly), say someone uses telnet to log into a system. Telnet prompts for the login ID. Once input, it passes forks off /bin/login with the login ID. /bin/login reads the user password information from /etc/shadow and takes the first two bytes from the password field (column 2 using : as field seperator) which is the crypt salt (see crypt man page). /bin/login prompts for the password which the user inputs. /bin/login takes the user input password and the salt value read from /etc/shadow for that user and pushes it through crypt. It then takes the resultant crypt output and compares it against what it read from /etc/shadow - if they matches the user has input the right password. If not, it prompts the user again with a password prompt.
3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.To change your password you run the passwd command. That command is SUID root - so for a short period of time you become root within the context of that process. Root is basically god mode and doesn't care about file access priviledges generally. So that fact that /etc/passwd and /etc/shadow have 000 file access permissions doesn't matter - root can still read and write to them.

How to recover /etc/passwd and /etc/shadow files

hi
Unfortunetly I have a big problem is that someone crash the /etc/passwd and /etc/shadow files from my running server, and my all users are not to able to login. so please can any one help me how to recover this files or any ideas for make these files...
thanks
Mohammed Tanvir

Hello
It is not working.Pla help me this bit critical
Step followed
01.Boot from the cdrom and mount root partision.
02.Deleted the exsisting file /etc/passwd and /etc/shadow
03.copy the opasswd and oshadow to the etc directory as passwd and shadow
04.Umount the root partision
05.Reeboot the system
thanks
Roshantha

Modifying /etc/passwd to run a script (with logging)

This is not Arch related so feel free to ignore...
The goal is to modify a users /etc/passwd entry so it runs a script instead of a shell.
As a proof of concept, this works:
#!/bin/bash
read -p "Enter your selection: " selection
case "$selection" in
1) /usr/bin/ssh [email protected];;
*) exit 0;;
esac
If I su to a user with that as their "shell" I see the prompt, I can press 1 and login to the remote box
Then I thought I'd try to add some logging and script became this:
#!/bin/bash
read -p "Enter your selection: " selection
case "$selection" in
1) /usr/bin/script -c "/usr/bin/ssh [email protected]";;
*) exit 0;;
esac
This does work when run directly at the command line but does not work when set as a users shell in /etc/passwd... it's like it executes the script over and over again. The output is:
Enter your selection: 1
Script started, file is typescript
Enter your selection: 1
Script started, file is typescript
So adding the /usr/bin/script to the mix is causing a problem.
What is the cause? I'm assuming it's something to do with subshells but I thought the '-c' would resolve that.
How can I make it do as expected (without modifying .profile if possible.) The end-goal is for users to log in and be presented with a list of servers to connect to
Is there a better way to accomplish this?
Last edited by oliver (2015-01-20 16:38:11)

I'm trying to avoid modifying profiles due to the archaic way we handle user accounts at work... it would be one more thing to maintain but it's certainly not impossible.
I think I will switch to /bin/sh anyway - just used bash out of habit
And reading the first post back, I'm not sure it's entirely clear... but it works at the command line and only fails when it's set as a user's shell. I'm not sure what the difference is
Last edited by oliver (2015-01-20 16:51:48)

Passwords for users listed in /etc/passwd

Do the predefined users listed in the /etc/passwd file have default passwords? The entry for each user password is *. Does this mean that the password is hidden or that it does not exist? In particular does the mysql user have a default password?
Any help would be most appreciated.
PowerPC G5 Mac OS X (10.4.6)

An entry with a single * means that the account's password is invalid, and therefore nobody can log into that account if a password is required to do so. More information is available in this article.
(11862)

/etc/passwd.pacnew

Similar Messages

Maybe you are looking for