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.


Does your remote support strategy keep you and your CEO awake at night?

Today’s remote support solutions offer much more than just remote control for PCs. Their functional footprint is expanding to include support for more devices and richer analytics for trend analysis and supervisor dashboards.

It is imperative that service executives acquaint themselves with the new features and capabilities being introduced by leading remote support platforms and find ways to leverage the capabilities beyond technical support.

Field services, education services, professional services, and managed services are all increasing adoption of these tools to boost productivity and avoid on-site visits.

Which product is easiest to deploy, has the best maintenance mode capabilities, the best mobile access and custom reporting, dynamic thresholds setting, and enhanced discovery capabilities?

To find out all you need to know about using remote support to improve your bottom line, download this FREE Whitepaper.


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.