Home Business IT Open Source UID and GID: the basics of Linux user admin

Whether your Linux box has hundreds of users or just one account for you and one for your dog it is important to understand how Linux user accounts work. There are GUI tools for this within GNOME and KDE but here we lift the lid on the bonnet to show what really makes a user exist, and what these commands are doing to your filesystem.

Being a multi-user system, Linux can allow many people to use the one computer. Each of these people is known as a “user” of the system. In fact, there may be many other users in Linux who are not even people – these might be programs running, like a Web server, that execute as a special user with limited access to the system.

Many users can be logged on to the one Linux computer all at the same time, by remote connections over the Internet or a network, or through terminals that boot from the Linux computer.

Linux has one special user called root. This super-user can read any file and write to any file. File permission restrictions do not affect the super-user.

Every other user is subject to file permission constraints. This means a typical user cannot wander into directories where they do not have permission. They can’t read files that they are not permitted to read. They can’t edit or delete files unless they are allowed to do so.

This is why we say above that programs like Web servers might run with limited access to the system – they will run under some sort of user account like “www” or “http”. The Web server can deliver files and take requests and can write to its own logs. The Web server might even run CGI programs to perform tasks like database manipulation. However, if the Web server runs under a typical user account, then a rogue CGI program can not, for example, delete the all-important password file. The CGI program is subject to file permission restrictions. If the Web server ran as root, the rogue CGI program could do any damage it liked.

Fortunately, most Linux distros enforce good security practices from the get-go by actively encouraging users to log in as an ordinary account, and only become root when required. This minimises the potential destructive power of root. One reason Linux is generally considered to have less security concerns than Windows is not even due to any software protection but simply this practice which was never generally enforced in the Windows world.


One of the most critical of all files in Linux is /etc/passwd. All user accounts are stored here, with identifying information like so:


For example, a user “fred” who was added as user 200 and group 100 has an entry that might look like this:

fred:x:200:100:Fred Smith:/home/fred:/bin/bash

Ironically, passwords are no longer stored in the password file and the “x” in the password field indicates this information is being shadowed. Originally, the encrypted password could be found here. By necessity, all users can read the password file which meant a glaring security risk existed; tools could very easily encrypted dictionary words and compare these to the contents of this file. By contrast, the shadow password file – generally /etc/shadow – is only readable by root.

WEBINAR 26/27th May

Thinking of deploying Business Intelligence (BI)? So are your competitors.

And the most important, fundamental, tool for delivering your BI information to your users? Dashboards.




VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!


David M Williams

joomla site stats

David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. Within two years, he returned to his alma mater, the University of Newcastle, as a UNIX systems manager. This was a crucial time for UNIX at the University with the advent of the World-Wide-Web and the decline of VMS. David moved on to a brief stint in consulting, before returning to the University as IT Manager in 1998. In 2001, he joined an international software company as Asia-Pacific troubleshooter, specialising in AIX, HP/UX, Solaris and database systems. Settling down in Newcastle, David then found niche roles delivering hard-core tech to the recruitment industry and presently is the Chief Information Officer for a national resources company where he particularly specialises in mergers and acquisitions and enterprise applications.






Join the iTWire Community and be part of the latest news, invites to exclusive events, whitepapers and educational materials and oppertunities.
Why do I want to receive this daily update?
  • The latest features from iTWire
  • Free whitepaper downloads
  • Industry opportunities