One of the interesting differences between Linux and Windows is in the file permission structure and management. While both operating systems are able to conceptually handle the same set of file management scenarios, they implement those permissions in different ways.
The Linux file system derives its implementation from Unix, which was released in 1973 and is much older than Windows. When Unix was first designed by AT&T, disk space was at a premium, and each bit on the hard drive mattered. In order to maximize disk space, each file could only have three sets of permissions – access permissions for everyone, access permissions for its “owning group”, and access permission for its “owning user”. Each of those three permissions could be defined as either Read, Write, or Execute. Let’s explore an example:
Owning User: Fred
Owning Group: Sales
Permissions: Everyone (Read), Sales (Read / Write), Fred (Read / Write)
As a result, everyone who has access to the server can read the file, while only Fred and the Sales department can read and write. The execute permission is primarily used when we want to allow a user to run a script or binary program.
The challenge in this scenario is what happens if we hire another person, Steve, who also needs write access to the file. If Steve is not in the Sales department, we will need to create a new group that encompasses both Steve and the Sales department, and replace the “Owning Group” with the new group. These permissions can quickly become messy in larger organizations with many similar outliers.
The Windows file system, on the other hand, takes permissions to the other extreme. Every file can have permissions assigned to it, for any number of users, any number of groups, or “Everyone”. There are even several different definitions of “Everyone” – authenticated users, guests, system users, network users, and so on. At the folder level, these fine-grained permissions can be set for inheritance by subfolders and children, so that any changes at the parent folder will be automatically replicated to its child subfolders.
On the other hand, in order to increase security, Linux added an additional concept called “SELinux”, or “Security-Enhanced Linux.” This operating system enhancement takes permissions to the next level, and enforces application-level and network-level permissions. Certain applications are allowed to access certain folders, while other programs cannot. While this adds significant flexibility in system security, debugging permission-based errors can be a challenge. The fine-grained application-level permissions can result in many days of fine-tuning in order to get a new Linux server ready for production. In addition, as applications on that server expand and require new features and packages, challenging or difficult-to-reproduce errors can occur due to the SELinux rules. On the whole, however, these rule-sets significantly help in preventing attacks from hackers and automated bots.
While both Linux and Windows approach permissions in a different way – with Windows offering fine-grained user-level control, while Linux offering application-level control, both operating systems reflect their end-user and application. With Windows as the primary platform for business networks, their permissions are ideal for file storage and management. Linux, on the other hand, offers a very effective permission structure for web and application servers, areas where it holds its own market dominance. As the two platforms grow over time, it will be interesting to see how their permission structures adapt to changing market demands.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.