Skip to main content

Where Linux User Group Information Stored

By
Where does linux stores user and group information?

User names and primary groups are stored in /etc/passwd. This file can be directly edited using the 'vi' editor, although this is not recommended. Format of the file is

* User name (normally all lower case)
* Password (encrypted - only contains the letter 'x')
* User ID (a unique number of each user)
* Primary Group ID
* Comment (Normally the person's full name)
* Home directory (normally /home/
* Default shell (normally /bin/bash)

Each field is separated by a colon.

for example:
# cat /etc/passwd
root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/bin/sh
daemon:x:2:2:daemon:/usr/sbin:/bin/sh
adm:x:3:4:adm:/adm:/bin/sh
lp:x:4:7:lp:/var/spool/lpd:/bin/sh
sync:x:5:0:sync:/bin:/bin/sync
shutdown:x:6:11:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
uucp:x:10:14:uucp:/var/spool/uucp:/bin/sh
operator:x:11:0:Operator:/var:/bin/sh
nobody:x:99:99:nobody:/home:/bin/sh
admin:x:1001:1000:admin:/home/admin:
guest:x:1002:1000:guest comment:/home/guest:
Says two users admin and guest on my linux box.
Also it is having cat /etc/passwd- file which contains same information as cat /etc/passwd

Passwords for each user are stored in /etc/shadow. This file should only be changed using the passwd command.

example:
# cat /etc/shadow
root:$1$yzGL7ddg$Eb9YHTiaMQ52qDUOkjHLM1:12963:0:99999:7:::
bin:*:12963:0:99999:7:::
daemon:*:12963:0:99999:7:::
adm:*:12963:0:99999:7:::
lp:*:12963:0:99999:7:::
sync:*:12963:0:99999:7:::
shutdown:*:12963:0:99999:7:::
halt:*:12963:0:99999:7:::
uucp:*:12963:0:99999:7:::
operator:*:12963:0:99999:7:::
nobody:*:12963:0:99999:7:::
admin:ddB035VORJOng:0:0:99999:7:::
guest:LkD5clThUzVjw:0:0:99999:7:::
 It is having cat /etc/shadow- file which contains same information as cat /etc/shadow

Group information is stored in /etc/group. This file can be directly edited using the 'vi' editor. Format of the file is

* Group name
* Group password (hardly ever used)
* Group ID
* User names (separated by commas)

Each field is separated by a colon.
example
# cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
lp:x:7:daemon,lp
uucp:x:14:uucp
ftp:x:50:
nobody:x:99:
users:x:100:
everybody:x:1000:admin,guest
administrators:x:1001:admin
 It is having cat /etc/group- file which contains same information as cat /etc/shadow
There are two groups everybody and administartors with users are admin,guest and admin respectively.
Labels:

Comments

Post a Comment

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

By
Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...
2 comments
Read more

Remote debugging for ARM target board

By
Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...
3 comments
Read more