File Permissions

Basic File Permissions

Permission Groups

Every file on your Linux system , including directories , is owned by a s pecific user and group.
Therefore, file permissiions are defined separately for users,groups,and others .

Each file and directory has three user based permission groups:

owner - The Owner permissions apply only the owner of the file or directory, they will not impact
the actions of other users.
group - The Group permissions apply only to the group that has been assigned to the file or
directory, they will not effect the actions of other users.
all users - The All Users permissions apply to all other users on the system, this is the
permission group that you want to watch the most.

Permission Types
Each file or directory has three basic permission types:

read - The Read permission refers to a user's capability to read the contents of the file.
write - The Write permissions refer to a user's capability to write or modify a file or directory.
execute - The Execute permission affects a user's capability to execute a file or view the
contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions by ls -l

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

User rights/Permissions

The first character that I marked with an underscore is the special permission flag that
can vary.
The following set of three characters (rwx) is for the owner permissions.
The second set of three characters (rwx) is for the Group permissions.
The third set of three characters (rwx) is for the All Users permissions.
The Fourth set is integer/number displays the number of hardlinks to the file.
The last piece is the Owner and Group.

ls -l /home
total 32
drwxr-x---. 38 editor editor 12288 Nov 30 10:49 editor
drwxr-x---. 4 greg development 4096 Nov 30 12:44 greg
drwx------. 21 gretchen gretchen 4096 Nov 30 11:26 gretchen
drwxr-xr-x. 41 ian ian 4096 Nov 30 10:51 ian
-rwxrwxr-x 1 mana mana 248 Mar 18 15:32 jt.sh
-rw-rw-r-- 1 mana mana 441 Mar 18 14:25 ThreadTest.class
-rw-rw-r-- 1 mana mana 560 Mar 18 15:10 ThreadTest.java

Other filesystem objects

The output from ls -l may contain filesystem objects other than files and directories as shown by
the first character in the listing.

Filesystem object types

Code Object type

- Regular file
d Directory
l Symbolic link
c Character special device
b Block special device
p FIFO
s Socket

The eleventh character

The eleventh character in a long listing from the ls command is a recent enhancement, so some
distributions may still show only the first ten characters. In other cases, the eleventh character is
a space, so you may not notice it. This character specifies whether an alternate access method
applies to the file. When the character following the file mode bits is a space, there is no
alternate access method. When it is a printing character, then there is such a method. The
method might be an access control list for example. GNU ls uses a '.' (dot) character to signify a
file with only an SELinux security context. Files with any other ombination of alternate access
methods are marked with the '+' (plus) character (if file set with ACL permission we will see +
mark).

Changing permissions
You can set file permissions with the chmod command. Both the root user and the file's owner
can set file permissions.

chmod has two modes , symbolic and numeric.

How to set file permissions - symbolic mode

The symbolic mode is pretty easy to remember. First, you decide if you set permissions for the
user (u), the group (g),others (o), or all of the three (a). Then, you either add a permission (+),
remove it (-), or wipe out the previous permissions and add a new one (=). Next, you decide if
you set the read permission (r), write permission (w), or execute permission (x).
Following are the symbolic representation of three different roles:
● u is for user,
● g is for group,
● and o is for others.
Following are the symbolic representation of three different permissions:
● r is for read permission,
● w is for write permission,
● x is for execute permission.

Following are few examples on how to use the symbolic representation on chmod.

The following symbols represent the permissions grant or revoke:

+ : Additional permissions. Selected permissions are added.

- : Revoke the permissions. Selected permissions are revoked.
= : Specific permissions. Only selected permissions are assigned.

1. Add single permission to a file/directory

Changing permission to a single set. + symbol means adding permission. For example, do the
following to give execute permission for the user irrespective of anything else:

$ chmod u+x filename

2. Add multiple permission to a file/directory

Use comma to separate the multiple permission sets as shown below.

$ chmod u+r,g+x filename

3. Remove permission from a file/directory

Following example removes read and write permission for the user.

$ chmod u-rx filename

Wipe out all the permissions but add read permission for everybody:

$ chmod u=r testfile

4. Change permission for all roles on a file/directory

Following example assigns execute privilege to user, group and others (basically anybody can
execute this file).

$ chmod a+x filename

5. Make permission for a file same as another file (using reference)
If you want to change a file permission same as another file, use the reference option as shown
below. In this example, file2′s permission will be set exactly same as file1′s permission.

$ chmod --reference=file1 file2

6. Change execute permission only on the directories (files are not affected)

On a particular directory if you have multiple sub-directories and files, the following command
will assign execute permission only to all the sub-directories in the current directory (not the files
in the current directory).

$ chmod u+X *

Note: If the files has execute permission already for either the group or others, the above
command will assign the execute permission to the user

7. Give read, write and execute permissions to everyone

$chmod ugo+rwx sample.sh

8. Give only read permissions to the user

$ chmod u=w sample.sh

How to set file permissions - numeric mode

Read, write and execute: 4+2+1=7

Give read, write and execute permissions to everyone.

$ chmod 777 sample.sh

Special Permissions

The special permissions flag can be marked with any of the following:

_ - no special permissions
s - This indicated the setuid/setgid permissions.
t - This indicates the sticky bit permissions.
i - immutable
when we execute these permission, we find below signs in the permission fields
Permissions Descriptions

--S------ SUID is set, but user (owner) execute permission is not set.

--s------ SUID and user execute persmission are set both.

-----S--- SGID is set, but group execute permission is not set.

-----s--- SGID and group execute permission are set both.

--------T Sticky bit is set, bot other execute permission is not set.

--------t Sticky bit and other execute permission are both set.

Changing file and folder permissions

Use the following commands to change file or folder permissions:

chmod (change file modes)
chown (change file owner)
chgrp (change file group owner)

The following letters represent

" u " - user/owner
" g " - group owner
" o " - all other users
" a " - for all: user/owner, group owner and all other users
" r " - read permission
" w " - write permission
" x " - execute permission
Examples of replacing and setting new permissions

(Note: Do not use space between any of the statements.

Example DO NOT TYPE: u = rwx)

# chmod u=rwx filename

# chmod u=rwx directoryname
# chmod -R u=rwx directoryname

# chmod g=rx filename

# chmod g=rx directoryname
# chmod -R g=rx directoryname

# chmod o=r filename

# chmod o=r directoryname
# chmod -R o=r directoryname

# chmod u=rwx,g=rx,o=r filename

# chmod u=rwx,g=rx,o=r directoryname
# chmod -R u=rwx,g=rx,o=r directoryname
# "-R" - means recursively change permissions of directories and their contents.
# chmod a=rwx filename
# "a" - for all: user/owner, group owner and all other users.
Examples of adding or taking away permissions from the current permissions
# chmod u+w filename
# chmod u+w directoryname
# chmod -R u+w directoryname

# chmod g+w filename

# chmod g+w directoryname
# chmod -R g+w directoryname

# chmod o-r filename

# chmod o-r directoryname
# chmod -R o-r directoryname

Modifying multiple permissions examples:

* chmod u+w,g+x,o-r filename
* chmod ug+rwx filename
* chmod ugo+rwx filename
* chmod u+w,g+x,o-r directoryname
* chmod ug+rwx directoryname
* chmod ugo+rwx directoryname
* chmod -R u+w,g+x,o-r directoryname
* chmod -R ug+w,o-r directoryname
* chmod -R ugo+rwx directoryname
* "-R" - means recursively change permissions of directories and their contents.

Examples of changing user/owner:

* chown username filename
* chown -R username directoryname

How to change owner of file use only colon?

$ chown mana: <filename>

Examples of changing user/owner using chgrp:

* chgrp groupname filename
* chgrp -R groupname directoryname

"-R" - means recursively change permissions of directories and their contents.

Here is some more examples:

chmod u=rwx,g=rw,o=rx myfile.txt
Now view the result:
ls -l myfile.txt
-rwxrw-r-x 1 user group 9482 Jan 16 16:29 myfile.txt

chmod -R u=rwx,g=rx,o=r directoryname

Now view the result:
ls -l directoryname
drwxr-xr-- 6 user group 204 Dec 30 06:37 images
-rwxr-xr-- 1 user group 5754 May 20 2005 index.html
-rwxr-xr-- 1 user group 9482 Jan 16 16:29 mypage.html

chown -R www directoryname

Now view the result:
ls -l directoryname
drwxr-xr-- 6 www group 204 Dec 30 06:37 images
-rwxr-xr-- 1 www group 5754 May 20 2005 index.html
-rwxr-xr-- 1 www group 9482 Jan 16 16:29 mypage.html

chgrp -R www directoryname

Now view the result:
ls -l directoryname
drwxr-xr-- 6 www www 204 Dec 30 06:37 images
-rwxr-xr-- 1 www www 5754 May 20 2005 index.html
-rwxr-xr-- 1 www www 9482 Jan 16 16:29 mypage.html

Access modes

SUID and GUID

SUID Bit
User excuted as owner of the file.

When an executable file runs, it runs under the ownership of the user who has executed it. It
means that when student user runs "ls" command then the corresponding process will run under
the ownership of student. The SUID bit, also known as Set User ID bit, overwrites this behavior.
If SUID bit is set on a program, then that program will run as the owner of that file, irrespective
of who is executing it.
The passwd command in Linux has SUID bit set.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 23420 Aug 3 2010 /usr/bin/passwd

This can be seen in the third field of permissions. The 's' in place of 'x' indicates that SUID bit is
set. With SUID bit set, when a normal user (say student) runs the passwd command, the
command runs with the ownership of 'root', and not as student, because root is the owner of this
file. This behavior is required because the passwords are stored in the /etc/shadow file, which
has no permission on group or other level.

$ ls -l /etc/shadow
-r-------- 1 root root 1027 Jul 13 21:56 /etc/shadow

You need to understand that all users cannot be given read or write permission on this file for
security reasons, otherwise they will read/change the passwords of other users. So this causes
a problem that if the users don't have permission on this file, then how will they change their
own passwords? So SUID bit solves the problem. The passwd command has SUID bit set, so
when normal users execute this command, they run it with the ownership of root, i.e. the owner
of passwd command.all users starting the passwd command execute it as root

The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or
search for directories) (x), execute/search only if the file is a directory or already has execute
permission for some user (X), set user or group ID on execution (s), restricted deletion flag or
sticky bit (t).

Setting and unsetting SUID bit

This is to be noted that SUID bit works on files only. To set the SUID bit on a file, use the chmod
command as follows

$ ls -l
total 8
-rwxr--r-- 1 root root 104 Aug 19 01:26 hello.sh

$ chmod u+s hello.sh

$ ls -l
total 8
-rwsr--r-- 1 root root 104 Aug 19 01:26 hello.sh

The numeric method for changing permissions can also be used. If the normal permissions for a
file are 744 (suppose), then with SUID bit set, these will become 4744. SUID bit has value 4.

$ ls -l
total 8
-rwxr--r-- 1 root root 104 Aug 19 01:26 hello.sh
$ chmod 4744 hello.sh

$ ls -l
total 8
-rwsr--r-- 1 root root 104 Aug 19 01:26 hello.sh

How to Find Files With setuid Permissions?

$ find / -user root -perm -4000 -exec ls -ldb {} \;

SGID Bit

Unlike SUID bit, SGID bit works on both files and directories, but it has different meaning in both
cases.

The setuid bit applies to users. However, there is also an equivalent property for groups: the
setgid bit. A program for which this bit was set runs under the group ID under which it was
saved, no matter which user starts it. Therefore, in a directory with the setgid bit, all newly
created files and subdirectories are assigned to the group to which the directory belongs.
Consider the following example directory:

drwxrws--- 2 tux archive 48 Nov 19 17:12 backup

You can see the s that denotes that the setgid bit is set for the group permission. The owner of
the directory and members of the group archive may access this directory. Users that are not
members of this group are “mapped” to the respective group. The effective group ID of all
written files will be archive. For example, a backup program that runs with the group ID archive
is able to access this directory even without root privileges.

On files:

For file, it has similar meaning as the SUID bit, i.e. when any user executes a file with SGID bit
set on it, it will always be executed with the group ownership of that file, irrespective of who is
running it. For example, the file /sbin/netreport has SGID bit set, which can be seen in the 's'
instead of 'x' in group permissions.

$ ls -l /sbin/netreport
-rwxr-sr-x 1 root root 6020 Oct 13 2010 /sbin/netreport

This file has group ownership of root group. So when a user (say student) executes it, then the
corresponding process will not have group ownership of student, but that of root group.

On directories:

Now let’s talk about SGID on directories. SGID on directories is used for creating collaborative
directories. To understand SGID bit on directories, consider the following scenario:
Suppose three users jack, jones and jenny are working together on some project. All of them
belong to a group named javaproject. For the course of the project, they need to share all the
files related to the project. All of them must be able to see each other's file. This can be done
simply by providing read permission on group level. Further suppose that the directory used for
the project is "/javaproject".

Here, a problem arises that when a file is created, it belongs to the primary group of the user
who created the file. So, when different users create their files in this directory, those files will
not have group ownership of javaproject group.

What we do for our problem is that we set the group of /javaproject directory to be javaproject
group, and set the SGID bit set on it. When SGID bit is set on a directory, all the files and
directory created within it has the group ownership of the group associated with that directory. It
means that after setting SGID bit on /javaproject directory, all the files and directories being
created in this directory will have the group ownership of "javaproject" group. Moreover, this
behavior is recursive, i.e. the directories created in this directory will have SGID bit set as well.
The permissions for the new directory will also be same as that of /javaproject directory.
The SGID bit can be set with chmod command as follows:

$ ls -ld /javaproject
drwxrwxr-x 2 root javaproject 4096 Aug 19 02:33 /javaproject
$ chmod g+s /javaproject
$ ls -ld /javaproject
drwxrwsr-x 2 root javaproject 4096 Aug 19 02:33 /javaproject

Now when jones user creates a file in this directory, it is created under the group ownership of
javaproject group.

[jones@redhat-server ~]$ touch /javaproject/jones1.txt

[jones@redhat-server ~]$ mkdir /javaproject/jones1dir
[jones@redhat-server ~]$ ls -l /javaproject/
total 12
drwxrwsr-x 2 jones javaproject 4096 Aug 19 02:38 jones1dir
-rw-rw-r-- 1 jones javaproject 0 Aug 19 02:37 jones1.txt

The numeric value corresponding to SGID bit is 2. So, to add SGID bit numerically, use the
following command:

$ ls -ld /shared/
drwxrwxr-x 2 root adm 4096 Aug 19 02:47 /shared/
$ chmod 2775 /shared/
$ ls -ld /shared/
drwxrwsr-x 2 root adm 4096 Aug 19 02:47 /shared/
Sticky Bit
There is also the sticky bit. It makes a difference whether it belongs to an executable program or
a directory. If it belongs to a program, a file marked in this way is loaded to RAM to avoid
needing to get it from the hard disk each time it is used. This attribute is used rarely, because
modern hard disks are fast enough. If this bit is assigned to a directory, it prevents users from
deleting each other's files. Typical examples include the /tmp and /var/tmp directories:

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

what if an user accidentally or deliberately deletes (or rename) a file created by some
other user in this directory?

Well, to avoid these kind of issues, the concept of sticky bit is used.A Sticky bit is a permission
bit that is set on a file or a directory that lets only the owner of the file/directory or the root user
to delete or rename the file. No other user is given privileges to delete the file created by some
other user.

The sticky bit works on directories only. If a user wants to create or delete a file/directory in
some directory, he needs write permission on that directory. The write permission on a directory
gives a user the privilege to create a file as well as the privilege to remove it.

The /tmp directory is the directory for temporary files/directories. This directory has all the rights
on all the three levels, because all the users need to create/delete their temporary files. But as
the users have write permission on this directory, they can delete any file in this directory. The
permissions of that file do not have any effect on deletion.

But with sticky bit set on a directory, anyone can create a file/directory in it, but can delete his
own files only. Files owned by other users cannot be deleted.

$ ls -ld /tmp/
drwxrwxrwt 4 root root 4096 Aug 19 02:29 /tmp/

Add Sticky Bit

The sticky bit can be set with chmod command with following methods:

Example:1

$ chmod o+t dir1

$ ls -l
total 8
drwxr-xr-t 2 root root 4096 Aug 19 03:08 dir1

Example:2

Turn ON the sticky bit on the directory by using +t flag of chmod command.
# chmod +t allAccess/

Remove sticky bit

$ chmod o-t dir1

$ ls -l
total 8
drwxr-xr-x 2 root root 4096 Aug 19 03:08 dir1

Sticky bit can be removed from a directory permissions through the -t option of the chmod
command.Here is an example :

# chmod -t allAccess/

Alternatively

$ chmod 1777 dir1/

$ ls -l
total 8
drwxrwxrwt 2 root root 4096 Aug 19 03:08 dir1

Make Important Files IMMUTABLE (Unchangeable) in Linux

chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain
attributes to a file in Linux system to secure accidental deletion or modification of important files
and folders, even though you are logged in as a root user.

This is very useful to set attributes in system files like passwd and shadow files wherein user’s
info are contains.

Syntax of chattr

# chattr [operator] [flags] [filename]

Attributes and Flags

Following are the list of common attributes and associated flags can be set/unset using the
chattr command.
● If a file is accessed with ‘A‘ attribute set, its atime record is not updated.
● If a file is modified with ‘S‘ attribute set, the changes are updates synchronously on the
disk.
● A file is set with ‘a‘ attribute, can only be open in append mode for writing.
● A file is set with ‘i‘ attribute, cannot be modified (immutable). Means no renaming, no
symbolic link creation, no execution, no writable, only superuser can unset the attribute.
● A file with the ‘j‘ attribute is set, all of its information updated to the ext3 journal before
being updated to the file itself.
 ● A file is set with ‘t‘ attribute, no tail-merging.
● A file with the attribute ‘d‘, will no more candidate for backup when the dump process is
run.
● When a file has ‘u‘ attribute is deleted, its data are saved. This enables the user to ask
for its undeletion.

Operator
● + : Adds the attribute to the existing attribute of the files.
● - : Removes the attribute to the existing attribute of the files.
● = : Keep the existing attributes that the files have.

1. How to add attributes on files to secure from deletion

To set attribute, we use the + sign and to unset use the - sign with the chattr command. So, let’s
set immutable bit on the files with +i flags to prevent anyone from deleting a file, even a root
user don’t have permission to delete it.

[root@tecmint tecmint]# chattr +i demo/

[root@tecmint tecmint]# chattr +i important_file.conf

Note: The immutable bit +i can only be set by superuser (i.e root) user or a user with sudo
privileges can able to set.

After setting immutable bit, let’s verify the attribute with command ‘lsattr‘.

[root@tecmint tecmint]# lsattr

----i----------- ./demo
----i----------- ./important_file.conf

Now, tried to delete forcefully, rename or change the permissions, but it won’t allowed says
“Operation not permitted“.

[root@tecmint tecmint]# rm -rf demo/

rm: cannot remove âdemo/â: Operation not permitted

[root@tecmint tecmint]# mv demo/ demo_alter

mv: cannot move âdemo/â to âdemo_alterâ: Operation not permitted

[root@tecmint tecmint]# chmod 755 important_file.conf

chmod: changing permissions of âimportant_file.confâ: Operation not permitted

2. How to unset attribute on Files

In the above example, we’ve seen how to set attribute to secure and prevent files from a
accidental deletion, here in this example, we will see how to reset (unset attribute) permissions
and allows to make a files changeable or alterable using -i flag.
[root@tecmint tecmint]# chattr -i demo/ important_file.conf

After resetting permissions, verify the immutable status of files using ‘lsattr‘ command.
[root@tecmint tecmint]# lsattr
---------------- ./demo
---------------- ./important_file.conf

You see in the above results that the ‘-i‘ flag removed, that means you can safely remove all the
file and folder reside in tecmint folder.

3. How to Secure /etc/passwd and /etc/shadow files

Setting immutable attribute on files /etc/passwd or /etc/shadow, makes them secure from an
accidental removal or tamper and also it will disable user account creation.

[root@tecmint tecmint]# chattr +i /etc/passwd

[root@tecmint tecmint]# chattr +i /etc/shadow

Now try to create a new system user, you will get error message saying ‘cannot open
/etc/passwd‘.
[root@tecmint tecmint]# useradd tecmint
useradd: cannot open /etc/passwd

This way you can set immutable permissions on your important files or system configuration
files to prevent from deletion.

4. Append data without Modifying existing data on a File

Suppose, you only want to allow everyone to just append data on a file without changing or
modifying already entered data, you can use the ‘a‘ attribute as follows.

[root@tecmint tecmint]# chattr +a example.txt

[root@tecmint tecmint]# lsattr example.txt

-----a---------- example.txt

After setting append mode, the file can be opened for writing data in append mode only. You
can unset the append attribute as follows.

[root@tecmint tecmint]# chattr -a example.txt

Now try to replace already existing content on a file example.txt, you will get error saying
‘Operation not permitted‘.

[root@tecmint tecmint]# echo "replace contain on file." > example.txt

-bash: example.txt: Operation not permitted

Now try to append new content on a existing file example.txt and verify it.
[root@tecmint tecmint]# echo "replace contain on file." >> example.txt

[root@tecmint tecmint]# cat example.txt

Here is the example to test 'a' attribute mean append only.
replace contain on file.

5. How to Secure Directories

To secure entire directory and its files, we use ‘-R‘ (recursively) switch with ‘+i‘ flag along with
full path of the folder.

[root@tecmint tecmint]# chattr -R +i myfolder

After setting recursively attribute, try to delete the folder and its files.
[root@tecmint tecmint]# rm -rf myfolder/
rm: cannot remove 'myfolder/': Operation not permitted

To unset permission, we use same ‘-R’ (recursively) switch with ‘-i’ flag along with full path of the
folder.
[root@tecmint tecmint]# chattr -R -i myfolder

Change file owner and group

Change File group

To change the group of a file, use the chgrp command with a group name and one or more
filenames. You may also use the group number if you prefer. An ordinary user must own the file
and also be a member of the group to which the file's group is being changed. The root user
may change files to any group.

Changing group ownership

[ian@echidna ~]$ touch file{1,2}
[ian@echidna ~]$ ls -l file*
-rw-rw-r--. 1 ian ian 0 Nov 30 15:54 file1
-rw-rw-r--. 1 ian ian 0 Nov 30 15:54 file2

[ian@echidna ~]$ chgrp development file1

[ian@echidna ~]$ chgrp 505 file2

[ian@echidna ~]$ ls -l file*

-rw-rw-r--. 1 ian development 0 Nov 30 15:54 file1
-rw-rw-r--. 1 ian development 0 Nov 30 15:54 file2

chgrp has a -R option to allow changes to be applied recursively to all selected files and
subdirectories.
Default group
When you studied Access modes above, you learned how setting the sgid mode on a directory
causes new files created in that directory to belong to the group of the directory rather than to
the group of the user creating the file.

You may also use the newgrp command to temporarily change your primary group to another
group of which you are a member. A new shell will be created, and when you exit the shell, your
previous group will be reinstated, as shown in Listing.

Using newgrp to temporarily change default group

[ian@echidna ~]$ groups
ian development editor
[ian@echidna ~]$ newgrp development
[ian@echidna ~]$ groups
development ian editor
[ian@echidna ~]$ touch file3
[ian@echidna ~]$ ls -l file3
-rw-r--r--. 1 ian development 0 Nov 30 16:00 file3
[ian@echidna ~]$ exit
[ian@echidna ~]$ groups
ian development editor

Change File owner

The root user can change the ownership of a file using the chown command. In its simplest
form, the syntax is like the chgrp command, except that a user name or numeric id is used
instead of a group name or id. The file's group may be changed at the same time by adding a
colon and a group name or id right after the user name or id. If only a colon is given, then the
user's default group is used. Naturally, the -R option will apply the change recursively. Listing
shows an example.

Using chown to changing file ownership

[root@echidna ~]# chown greg ~ian/file4
[root@echidna ~]# chown tom:gretchen ~ian/file4
[root@echidna ~]# ls -l ~ian/file4
[root@echidna ~]# chown :tom ~ian/file4
[root@echidna ~]# ls -l ~ian/file4
-rw-rw-r--. 1 tom tom 0 Nov 30 16:04 /home/ian/file4

UMASK

Controlling file permissions with umask

When user create a file or directory under Linux, the default permissions are assigned by the
system, and these are governed by the umask setting in login.defs file. Most of the Linux distros
give 022 (0022) as default UMASK.Defaut file and folder Creation Permissions that file has 666
permissions and directory with 777 permissions

Unless set up by yourself or the system administrator, your default umask setting will be 0000,
which means that new files you create will have read and write permission for everyone (0666
or -rw-rw-rw-), and new directories that you create will have read, write and search permissions
for everyone (0777 or drwxrwxrwx). You will almost certainly want to change your umask setting
to a non-zero value, to make the default values to the newly created files and directories more
restrictive.

You can change the default permission by using the umask command.

How do set umask

$ umask 022

The digits in the umask number are 'subtracted' from 777 for directories or 666 for files when
you are creating their initial permissions.

Then when you create new files their default permissions will be 644 (666 minus 022, i.e.
-rw-r--r--). When you create new directories their default permissions will be 755 (drwxr-xr-x).

Task: Calculating The Final Permission For FILES

You can simply subtract the umask from the base permissions to determine the final permission
for file as follows:
666 - 022 = 644
● File base permissions : 666
● umask value : 022
● subtract to get permissions of new file (666-022) : 644 (rw-r--r--)

Task: Calculating The Final Permission For DIRECTORIES

You can simply subtract the umask from the base permissions to determine the final permission
for directory as follows:
777 - 022 = 755
● Directory base permissions : 777
● umask value : 022
● Subtract to get permissions of new directory (777-022) : 755 (rwxr-xr-x)

For reference, the following table shows the mappings between umask values and default
permissions. BE VERY CAREFUL not to confuse umask and chmod permissions, as they are
entirely different (a binary inversion of each other) and are NOT INTERCHANGABLE!!
How Do I Calculate umasks?
The octal umasks are calculated via the bitwise AND of the unary complement of the argument
using bitwise NOT. The octal notations are as follows:
■ Octal value : Permission
■ 0 : read, write and execute
■ 1 : read and write
■ 2 : read and execute
■ 3 : read only
■ 4 : write and execute
■ 5 : write only
■ 6 : execute only
■ 7 : no permissions

To discover what umask you are currently working with, type:

$ umask

If you set umask at the shell prompt, it will only apply to the current login session. It will not
apply to future login sessions. To apply umask setting automatically at login, you would add the
umask command to your .login file (C Shell users) or .profile (Bourne and Korn Shell users).

Procedure To Setup Default umask

You can setup umask in /etc/bashrc or /etc/profile file for all users. By default most Linux distro
set it to 0022 (022) or 0002 (002). Open /etc/profile or ~/.bashrc file, enter:

# vi /etc/profile
OR
$ vi ~/.bashrc

Append/modify following line to setup a new umask:

umask 022
Save and close the file. Changes will take effect after next login. All UNIX users can override the
system umask defaults in their /etc/profile file, ~/.profile (Korn / Bourne shell) ~/.cshrc file (C
shells), ~/.bash_profile (Bash shell) or ~/.login file (defines the user's environment at log

caveat: you cannot setup a umask per directory as it's a process level thing.

You cannot set umask per directory, it's a process-level value. If you need to prevent others from
reading files in a directory, revoke the corresponding permissions bits.

For example, if you've a directory /home/user/directory with some files and directories which can
get permissions like 777 from a process, set the permission bits of /home/user/directory to
something like 700. That will make it impossible for other users (excluding the superuser root) to
descend in /home/user/directory.

How Do I Set umask Using Symbolic Values?

The following symbolic values are used:
1. r : read
2. w : write
3. x : execute
4. u : User ownership (user who owns the file)
5. g : group ownership (the permissions granted to other users who are members of the
file's group)
6. o : other ownership (the permissions granted to users that are in neither of the two
preceding categories)
The following command will set umask to 077 i.e. a umask set to u=rwx,g=,o= will result in new
files having the modes -rw-------, and new directories having the modes drwx------:

$ umask u=rwx,g=,o=
$ mkdir dir2
$ touch file2
$ ls -ld dir2 file2

Access Control Lists in Linux (ACL)

ACLs can be used as an extension of the traditional file permission concept. They allow the
assignment of permissions to individual users or groups even if these do not correspond to the
original owner or the owning group. Access control lists are a feature of the Linux kernel and are
currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS. Using ACLs,

Prerequisites

Filesystem options
Before using ACL's we must first verify that our filesystem has the acl option enabled.
A common way to enable acl support on a filesystem is to add the acl option to a filesystems
mount options in /etc/fstab. We can check if that has been done on this system by using the
mount command.
root@testvm:~# mount | grep root
/dev/mapper/workstation-root on / type ext4 (rw,errors=remount-ro)

In this case the acl option has not been added but that doesn't mean our filesystem doesn't
have acl's enabled. On most distributions the default filesystems have the acl option as part of
the default mount options. You can check if your filesystems have acl as part of the defaults by
using the tune2fs command.

root@testvm:~# tune2fs -l /dev/mapper/workstation-root

tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: f558402c-a418-4892-87e2-071c1a85898c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery
extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl

As you can see on my test system the default mount options contain acl, in this case my
filesystem will support acl's even if I don't specify it during the mount process. If your filesystem
does not have acl as a default mount option, than you can add it during the mount process
easily by editing the fstab file.

root@testvm:~# vi /etc/fstab

Simply add the term acl to the mount options as shown below.

/dev/mapper/workstation-root / ext4 acl,errors=remount-ro 0 1

Once your fstab file is edited you can remount your filesystem with the mount command.

root@testvm:~# mount -o remount /

root@testvm:~# mount | grep root
/dev/mapper/workstation-root on / type ext4 (rw,acl,errors=remount-ro)

Setting and listing acl's with getfacl and setfacl

To modify ACL use setfacl command. To add permissions use setfacl -m.

Add permissions to some user:

# setfacl -m "u:username:permissions"

or
 # setfacl -m "u:uid:permissions"

Add permissions to some group:

# setfacl -m "g:groupname:permissions"

or
# setfacl -m "g:gid:permissions"

The m - option tells setfacl to modify specified file and directory

Checking the ACL list with getfacl

Once you've set the acl with setfacl it is common sense to check if it took effect, in order to do
so you will need to use the getfacl command.

# getfacl {filename or directory}

root@testvm:/var/tmp# getfacl appdir/

# file: appdir/
# owner: root
# group: appgroup
user::rwx
group::rwx
group:testusers:r--
mask::rwx
other::r-x

Identifying files/directories that have ACL's(Output of ls command)

While the standard unix permissions are displayed with the ls -l command; the defined ACL's
are a little more verbose and are not a part of the long listing. The command ls will tell you if a
file or directory does have acl's, it's just not that obvious.

root@testvm:/var/tmp# ls -la | grep appdir

drwxrwxr-x+ 2 root appgroup 4096 May 27 10:45 appdir

As you can see there is now a + at the end of the directories permissions. This + is the indicator
that this file or directory has acl's, from here you can use the getfacl command to see what they
are.

Remove ACL permmisions

Removing all acl entries from a file or directory

# setfacl -b abc
b - option that this will remove all of the acl rules on the specified file or directory.

Removing only specifiedl acl entries from a file or directory

setfacl -x u:testuser1 {file or directory}

x - option will only remove the specified rule

Examples of Usage

Use Cases
1. Removing all acl entries from a file or directory
2. Set test users to have read access to all files in a directory
3. Set the same acl changes recursively
4. Set the same acls on all newly created files automatically
5. Set testuser1 to have read, write and execute access to the appuser1 directory
6. Set all users to have read, write and execute access to the shared directory
7. Remove the acl for testuser1 on appuser1 directory

1. Removing all acl entries from a file or directory

# setfacl -b filename or directory

2. Set testusers to have read access to all files in the appdir directory

we want the testusers group to have read access to all files in the appdir directory.

# setfacl -m g:testusers:r appdir/

3. Set the changes recursively

The appdir has 2 sub directories appdir/appuser1 and appdir/appuser2 in this case we want the
acl rules set above to apply to these directories as well. This can easily be accomplished by
adding the -R (recursive) option in setfacl. This works exactly like the recursive option for
chmod.

# setfacl -Rm g:testusers:r appdir/

4. Set the same acl's on all newly created files automatically

The -d (default) option in setfacl is extremely useful; this option will allow us to set an acl rule to
be the default rule. When this is set on a directory this makes all new files or directories created
within that directory inherit the same acl rules.
 # setfacl -dm g:testusers:r appdir/

As you can see dir1 also have the default acl rules as appdir, yet appuser1 does not. This is
because we did not set the default recursively; this can be done by using the -R option.

# setfacl -Rdm g:testusers:r appdir/

5. Set testuser1 to have read, write and execute access to the appuser1 directory

While the user testuser1 is in the testusers group and has read access to the appuser1 directory
he does not have write access. In this case we want to give him write access without giving the
rest of the testusers write access. This can be done using acl's by specifying a specific user
rather than a group.

# setfacl -m u:testuser1:rwx appdir/

6. Set all users to have read, write and execute to the shared directory

We have now given users and groups permissions on directories and files, but what happens
when we want all users to have access to a directory? Adding every users name or group could
get tedious, in this case we can set the "other" or "world" permissions so that all users on a
system can access this directory.

# setfacl -m o::rwx shared

You might be asking yourself right now "wait a minute, did setfacl just set the permissions to
757?"; why yes it did! ACL's are just an extension of the standard unix permissions, in this case
because we are not specifying a user or group; setfacl will simply just change the mode of the
file. Tricky, yes I know.

7. Remove the acl for testuser1 on appuser1 directory

Unlike the -b option that removes all acl's on a directory or file the -x option will only remove the
specified rule. This is useful for when you maybe fat fingered an acl rule and don't want to
completely remove all of the acl rules attached to that file/directory.

# setfacl -x u:testuser1 appdir/

8. How to share the directory among the marketing-g and sales-g groups and the user
named george. Sales, marketing and george need to have full access to the directory
including the creation of new files in that directory.

$ setfacl -m user:george:rwx,group:sales-g:rwx,group:marketing-g:rwx projections

OR
$ setfacl -m u:george:rwx,g:sales-g:rwx,g:marketing-g:rwx projections
 $ getfacl projections/

# file: projections
# owner: peter
# group: peter
user::rwx
user:george:rwx
group::r-x
group:sales-g:rwx
group:marketing-g:rwx
mask::rwx
other::r-x

9. How do you fix this issue "chmod 444 /bin/chmod"?

Solution:

# /usr/bin/setfacl --set u::rwx,g::r-x,o::r-x /bin/chmod

# /usr/bin/perl -e 'chmod 0755, qw(/bin/chmod)'

set - set the ACL of file(s), replacing the current ACL