File Management
POS 355
30 September 2013
Paul Rouk

File Management
According to Stallings (2012), “In most applications, the file is the central element.” A large number of UNIX operating systems are established on file access control. Unfortunately, permissions for both read and write cannot be assigned to only a certain number of users on the access control list (ACL). Suppose a system that must support 5,000 users was needed but only 4,990 are required to access one file, this would result in need for two user groups to be created, one group with read only permissions and another group for read and write permissions. Before implementing this protection scheme, a basic knowledge of file management hierarchy is needed.
UNIX operating systems are established on file access control schemes. Every user is given an exclusive user ID along with a password to access the system. The user is also part of a primary group, which are identified with a group ID (GID). Every group has different access permissions, depending on the needs of the users within the group. They can range from read, write, and execute. By defining the permissions of each group, the users within that group can only perform the permissions assigned to them. This establishes file security because a user cannot change permissions assigned to them unless they are the superuser, known as “root”. For security measures, the superuser should be a UNIX administrator because the superuser or root has access to the complete system and is not controlled by the permissions set to the users, groups, or ACLs.
The superuser or root has the capability of assigning users, groups, and permissions. Before the root can create a group, the needs and accompanying permissions, must be defined. Permissions have to apply to the group as a whole and not just to part of the group and not the other. Once the requirements have been established, the root can perform the different commands in the command prompts. The root must first log in and then create the group. The command mkgroup candle will create the group named candle. To create a user within the group candle, the command mkuser votive must be executed. This creates the user votive. To make the user part of the group candle, the superuser root must execute the command: mkuser pgrp=candle home=home/home/candle. This establishes that the user_votive belongs to the primary group candle and the home directory for user_votive is the same home directory as the group candle. I believe in order to add more users to the group; each user must be added individually. Once the users have been added to the group and permissions have been set for each individual of the group by using sefacl –m user:user:rw- CandleDirectory, the permissions for the group ID and the ACL can be established.
Permissions can be added to the directory of files that the group will use by using the setfacl command. According to, Rob Henderson (2010), To set the permissions for the ACL for this directory, the command “setfacl –m default:user::rw-,default:group::---default:maskrwx,default:other:---CandleDirectory”. By setting the individual permissions when creating the users before the ACL permissions were set, allows this command to set only the owner of the directory read, write, and execute permissions.
It is important for the 4,990 users to read and write to the files to further progress in their work and the command above only gives the owner of the directory of files the read, write, and execute permissions. I believe that it is essential to keep the execute permissions to a minimum to deter from unnecessary acts of removing files.
By giving users unique user IDs, such as last name_first initial and placing them into groups, ACL permissions can be set. This helps protect the system because not all users will be able to execute most commands, they can only read and write to the existing files. Assigning permissions is essential so valuable data is not removed or corrupted either by accident or by intentional malicious acts.