Linux file permission: Difference between revisions

From HPCWIKI
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Traditional file permission ==
== Linux Regular(default) Permission ==
ls command witl -al option to view the permissions (or '''file mode''') set for the contents of a directory<syntaxhighlight lang="bash">
ls command witl -al option to view the permissions (or '''file mode''') set for the contents of a directory<ref>https://wiki.archlinux.org/title/File_permissions_and_attributes</ref><syntaxhighlight lang="bash">
$ ls -al /
$ ls -al /
total 2098648
total 2098648
Line 28: Line 28:
drwxr-xr-x  15 root    root            4096 May 18 15:36 usr
drwxr-xr-x  15 root    root            4096 May 18 15:36 usr
drwxr-xr-x  13 root    root            4096 Dec  5 17:31 var
drwxr-xr-x  13 root    root            4096 Dec  5 17:31 var
</syntaxhighlight>Following table explains what is the meaning of character you should focus
</syntaxhighlight>
 
 
[[File:Linux regular permission.png|center|frameless|436x436px|linux regular permission]]
{| class="wikitable"
{| class="wikitable"
|d
|+
|rwx
!Type
|rwx
!Description
|rwx
| +
|-
|-
|The file type, technically not part of its permissions
| rowspan="2" |SUID
|The permissions that the '''owner''' has over the file, explained below.
|When the SUID bit is set on an executable file,  
|The permissions that the '''group''' has over the file, explained below.
this means that the file will be executed with the same permissions as the owner of the executable file.
|The permissions that all '''the other''' users have over the file, explained below.
 
|A single character that specifies whether an alternate access method applies to the file. When this character is a space, there is no alternate access method. A <code>.</code> character indicates a file with a security context, but no other alternate access method. A file with any other combination of alternate access methods is marked with a <code>+</code> character, for example in the case of Access Control Lists.
The passwd command is the best example for SUID. if we look at the file in detail
|}
Each of rwx(s) permission meaning,
{| class="wikitable"
!rwx(s/S)
!Owner ship
!Character
!
!Effect on files
!Effect on directories
|-
|-
! rowspan="2" |Read permission (first character)
|$ ls -l /usr/bin/passwd
| rowspan="2" |owner
-rwsr-xr-x 1 root root 68208 May 27  2020 /usr/bin/passwd
|<code>-</code>
 
|
 
|The file cannot be read.
SUID can be set by
|The directory's contents cannot be shown.
 
<nowiki>#</nowiki>chmod u+s file_name or #chmod 4755 file_name
 
 
and can be removed by
 
<nowiki>#</nowiki>chmod u-s file_name or #chmod 0755 file_name
 
 
SUID set files can be found by
 
<nowiki>#</nowiki>find / '''-perm''' /4000
 
 
Tip, Capital S as SUID flag means there is an error that you should look into
|-
|-
|<code>r</code>
| rowspan="2" |SGID
|4
|SGID is similar to SUID, With the SGID bit set, any user executing the file will have same permissions as the group owner of the file.
|The file can be read.
 
|The directory's contents can be shown.
*If set on a file, it allows the file to be executed as the '''group''' that owns the file (similar to SUID)
* If set on a directory, any files created in the directory will have their '''group''' ownership set to that of the directory owner
 
 
It’s benefit is in handling the directory. When SGID permission is applied to a directory, all sub directories and files created inside this directory will get the same group ownership as main directory.
 
 
A practical example of SGID is with '''[[Samba]] server''' for sharing files on your local network. It’s guaranteed that all new files will not lose the permissions desired, no matter who created it.
|-
|-
! rowspan="2" |Write permission (second character)
|$ ls -ld /var/local
| rowspan="2" |group
drwxrwsr-x 2 root staff 4096 Apr 15  2020 /var/local
|<code>-</code>
 
|
 
|The file cannot be modified.
SGID bit can be set by
|The directory's contents cannot be modified.
 
<nowiki>#</nowiki>chmod g+s directory_name or #chmod 2755 directory_name
 
 
SGID bit can be removed by
 
<nowiki>#</nowiki>chmod g-s directory_name or #chmod 0755 directory_name
 
 
Or find by
 
find . -perm /2000
|-
|-
|<code>w</code>
| rowspan="2" |Sticky Bit
|2
|The sticky bit works on the directory (Under [[linux]], this permission does not affect individual files).  With sticky bit set on a directory, all the files in the directory can only be deleted or renamed by the file owners only or the root.
|The file can be modified.
 
|The directory's contents can be modified (create new files or directories; rename or delete existing files or directories); requires the execute permission to be also set, otherwise this permission has no effect.
 
This is typically used in the '''/tmp directory''' that works as the trash can of temporary files.
|-
|-
! rowspan="6" |Execute permission (third character)
|$ ls -ld /tmp
| rowspan="2" |the other
drwxrwxrwt 11 root root 4096 Feb 27 18:40 /tmp
|<code>-</code>
 
|
sticky bit can be set by
|The file cannot be executed.
 
|The directory cannot be accessed with cd.
<nowiki>#</nowiki>chmod +t directory_name  or #chmod 1755 directory_name
|-
 
|<code>x</code>
Sticky bit can be removed by
|1
 
|The file can be executed.
<nowiki>#</nowiki> chmod -t directory_name or #chmod 0755 directory_name
|The directory can be accessed with cd; this is the only permission bit that in practice can be considered to be "inherited" from the ancestor directories, in fact if ''any'' directory in the path does not have the <code>x</code> bit set, the final file or directory cannot be accessed either, regardless of its permissions; see path_resolution(7) for more information.
 
|-
And find by
|SUID/GUID
 
|<code>s</code>
<nowiki>#</nowiki>find . -perm /1000
|4/2
| colspan="2" |The setuid bit when found in the '''u'''ser triad; the '''setgid''' bit when found in the '''g'''roup triad; it is not found in the '''o'''thers triad; it also implies that <code>x</code> is set.
|-
|
|<code>S</code>
|
| colspan="2" |Same as <code>s</code>, but <code>x</code> is not set; rare on regular files, and useless on directories.
|-
|Sticky
|<code>t</code>
|1
| colspan="2" |The sticky bit; it can only be found in the '''o'''thers triad; it also implies that <code>x</code> is set.
|-
|
|<code>T</code>
|
| colspan="2" |Same as <code>t</code>, but <code>x</code> is not set; rare on regular files.
|-
!+
|
|
|
| colspan="2" |"+" to indicate that there is an extended ACL for this item
|}
|}


== SUID, GUID, and Sticky ==
SUID and GUID mean that for executable commands, they run as user and group respectively.


The sticky bit - originally implemented in UNIX meant a program stayed in RAM after running- Under [[linux]], it means that anyone can create folders or files in the directory, but they can only be removed by that user.  
In numerical method,  need to pass a fourth, preceding pre-defined special digit in our <code>chmod</code> command
* Default 0, SUID = 4, SGID = 2, Sticky = 1
 
The syntax is:
<code>$ chmod X### file | directory</code>
 
== Linux Extended ACL ==
Extended ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing the base ownership and permissions. Default permissions can be set only for one owner, one group and Other users. So different permissions cannot be configured for different users and groups.
 
 
On Linux, Extended ACL shows "+" information when do $ls -al command. we can manage the ACL with "'''getfacl'''" and "'''setfacl'''" on the command line.
[[File:Linux extended acl.png|center|frameless|400x400px]]
 
=== Listing access control lists ===
'''The getfacl command is used on Linux to print a complete listing of all regular permissions and access control lists permissions on a file or directory.'''
 
'''$ getfacl <file, directory>'''<syntaxhighlight lang="bash">
# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
#The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries
</syntaxhighlight>
 
=== Setting access control lists using setfacl ===
The setfacl has the following syntax,
 
 
$ setfacl [action] <what>:<user/group>:<permissions>
 
'''$ setfacl {-m, -x, -d, -b}  {u, g}:<name>:[r, w, x] <file, directory>'''
 
* '''-m''' : (set or modify) means that you want to '''modify''' one or several ACL entries on the file or directory.
* '''-x''' : (delete) means that you want to '''remove''' one or several ACL entries on a file or directory.
* -d : (default) means specific type of permission assigned to a directory, that doesn’t change the permissions of the directory itself
* -b :  with -b option, you can erase all the ACLs set<ref>https://linuxconfig.org/how-to-manage-acls-on-linux</ref>
* '''{u, g}''' : if you want to modify the ACL for a user or for a group.
* '''name''' : this is an optional parameter, it can be omitted if you want to set the ACL entries for every user or for every group on your host.
* '''[r, w, x]''' : in order to set read, write or execute permissions on the file or directory.
 
<syntaxhighlight lang="bash">
Example,
 
To set specific write permissions for a user on a file
$ setfacl -m u:user:w <file, directory>  
 
To set execute permissions for all users on your host
$ setfacl -m u::x <file, directory>    
 
To set full permissions for a specific group on your host
$ setfacl -m g:group:rwx <file, directory>
 
To remove a user specific entry from a file,
$ setfacl -x u:<user> <file, directory>
 
To remove ACL related to groups on your host
$ setfacl -x g:<group> <file, directory>
 
To allow rwx to accouting group for accounting folder
$ setfacl -d -m accounting:rwx /accounting
 
To modify user2 be rwx, group admin rwx for myfolder
$ setfacl -m "u:user2:rwx,g:admin:rwx" myfolder
 
</syntaxhighlight>
 
=== Creating defaults access control lists  on directories ===
'''defaults access control lists  are used to create ACL entries on a directory that will be inherited by objects in this directory like files or subdirectories. it is recommended to specify default permissions for all three categories (user, group and other)'''
 
 
To create default ACL entries syntax,
 
$ setfacl -d -m {u, g}:<name>:[r, w, x] <directory>
 
<syntaxhighlight lang="bash">
For example,
 
to assign read permissions to all files created in a directory,
$ setfacl -d -m u::r directory
 
To delete default existing access control lists on directories, use the -k flag
$ setfacl -k <directory>
 
To remove default ACL entries in a directory and all subdirectories, you would have to use a recursive option (-R)
$ setfacl -kR <directory>
</syntaxhighlight>
 
=== Working with the access control lists mask ===
The ACL mask is different from the file creation mask (umask) and it is used in order to restrict existing ACL entries existing on a file or directory.
 
The ACL mask is '''updated every time you run a setfacl command unless you specify that you don’t want to update the mask with the -n flag.'''<syntaxhighlight lang="bash">
To prevent the mask from being updated,
$ setfacl -n -m u:antoine:rwx <file, directory>
</syntaxhighlight>
 
Following example show how mask is mapping to user and group<ref>https://www.learnitguide.net/2015/12/setting-up-access-control-lists-acl-on.html</ref><syntaxhighlight lang="bash">
# file: myfolder
# owner: user1
# group: [[test]]
user::rwx
user:user2:rwx          # effective: r-x due to mask
group::r-x
group:admin:rwx        # effective: r-x due to mask
mask::r-x              # mask effective to user and group
other::---
</syntaxhighlight>


== Umask ==
== Umask ==
Line 145: Line 254:




To set the umask value through the ''umask'' command
To set the umask value through the ''umask'' command,


System-wide umask value can be set in <code>/etc/profile or in the default shell configuration files (e.g. /etc/bash.bashrc) in most Linux distributions.</code>
System-wide umask value can be set in <code>/etc/profile or in the default shell configuration files (e.g. /etc/bash.bashrc) in most Linux distributions.</code>
Line 162: Line 271:
  # session    optional  pam_umask.so        umask=022
  # session    optional  pam_umask.so        umask=022


== Permission change ==
== File Attributes ==
{| class="wikitable"
Apart from the file mode bits that control user and group read, write and execute permissions, several file systems file attributes that enable further customization of file operations.
|+
!Text method
!Octal method
!Result
!Meaning
|-
|$ chmod g= fileordir
$ chmod o= fileordir
|$chmod 700 fileordir
|<code>drwx------</code>
|just = means deny permission
|-
|$ chmod g=rx fileordir
$ chmod o=rx fileordir
or
$chmod go=rx fileordir
|$chmod 755 fileordir
|<code>drwxr-xr-x</code>
|set group to rx
set others to rx
|-
|
|
|
|
|}


== Extended ACL ==
Extended attributes can be changed with chattr and listing them with lsattr which is included in e2fsprogs package. [https://ngelinux.com/what-is-chattr-and-lsattr-command-in-linux-and-how-to-use-them/ this page] explained details how to use lsattr and chattr
Extended ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing the base ownership and permissions. Default permissions can be set only for one owner, one group and Other users. So different permissions cannot be configured for different users and groups.
we can manage the ACL with "'''getfacl'''" and "'''setfacl'''" on the command line<syntaxhighlight lang="bash">
# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
#The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries
</syntaxhighlight>


== Setting an Extened ACL ==
<lsattr | chattr> [+|-] [attributes] <filename>
The syntax for setting an ACL is


$setfacl [action] <what>:<user/group>:<permissions>
These are a few useful attributes. Not all filesystems [[support]] every attribute.
{| class="wikitable"
|+
!
!action
!what:suer/group:permissions
!notes
!
!
|-
|options
|<code>-m</code> (set/modify)
| rowspan="3" |u (user)
g (group)
o (others)
m (mask)
|'''mask''' associated with an ACL limits the set of permissions that can be assigned on the file for the the named groups and users and for the group owner, but has no effect on the permissions for the file owner and the <code>other</code> permission group
|
|
|-
|
|<code>-x</code> (delete)
|
|
|
|-
|
|<code>-d</code> (defaults)
|default is a specific type of permission assigned to a directory, that doesn’t change the permissions of the directory itself, but makes it so that the specified ACLs are set by default on all the files created inside of it.
|
|
|-
|
| -b (remove all)
|
|with -b option, you can erase all the ACLs set<ref>https://linuxconfig.org/how-to-manage-acls-on-linux</ref>
|
|
|}
<code># setfacl -d -m accounting:rwx /accounting</code><syntaxhighlight lang="bash">
## modify user2 be rwx, group admin rwx for myfolder
# setfacl -m "u:user2:rwx,g:admin:rwx" myfolder 


</syntaxhighlight>Following example show how mask is mapping to user and group<ref>https://www.learnitguide.net/2015/12/setting-up-access-control-lists-acl-on.html</ref><syntaxhighlight lang="bash">
* <code>a</code> - append only: File can only be opened for appending. like i, but can only be appended.
# file: myfolder
# owner: user1
# group: [[test]]
user::rwx
user:user2:rwx          # effective: r-x due to mask
group::r-x
group:admin:rwx        # effective: r-x due to mask
mask::r-x              # mask effective to user and group
other::---
</syntaxhighlight>
 
== File Attributes ==
Apart from the file mode bits that control user and group read, write and execute permissions, several file systems [[support]] file attributes that enable further customization of file operations.
 
Extended attributes can be changed with chattr and listing them with lsattr which is included in e2fsprogs package
 
These are a few useful attributes. Not all filesystems support every attribute.
 
* <code>a</code> - append only: File can only be opened for appending.
* <code>c</code> - compressed: Enable filesystem-level compression for the file.
* <code>c</code> - compressed: Enable filesystem-level compression for the file.
* <code>i</code> - immutable: Cannot be modified, deleted, renamed, linked to. Can only be set by root.
* <code>i</code> - immutable: Cannot be modified, deleted, renamed, linked to. Can only be set by root. with this bit set, the file becomes the unmovable object. No writes, not from the kernel or daemons, and not from the root user.
* <code>j</code> - data journaling: Use the journal for file data writes as well as metadata.
* <code>j</code> - data journaling: Use the journal for file data writes as well as metadata.
* <code>m</code> - no compression: Disable filesystem-level compression for the file.
* <code>m</code> - no compression: Disable filesystem-level compression for the file.
Line 278: Line 288:
* <code>C</code> - no copy on write: Disable copy-on-write, for filesystems that support it.
* <code>C</code> - no copy on write: Disable copy-on-write, for filesystems that support it.


<nowiki>**</nowiki>If root cannot delete or modify some file, that file should have a and i file attributes. some virus or malware use this attributes to execute process under Linux. 


if root user cannot delete or modify some file, that file should have a and i file attributes. some virus or malware use this attributes to execute process under Linux.
== Extended Attributes (xattrs) ==
 
== Extended Attributes ==
xattr - Extended attributes are name:value pairs associated permanently with files and directories defines four extended attribute classes: security, system, trusted and user.
xattr - Extended attributes are name:value pairs associated permanently with files and directories defines four extended attribute classes: security, system, trusted and user.


archlinux provides great information about [https://man.archlinux.org/man/xattr.7 xattr] and [https://wiki.archlinux.org/title/Capabilities capability]
archlinux provides great information about [https://man.archlinux.org/man/xattr.7 xattr] and [https://wiki.archlinux.org/title/Capabilities capability]
<nowiki>**</nowiki>'''unlike ACLs, xattrs do not show up anywhere but with lsattr'''<ref>https://www.linkedin.com/pulse/linux-permissions-anything-simple-jack-barber</ref>
== POSIX Capabilities ==
POSIX 1003.1e capabilities are role/action based capabilities that that allow certain root-only tasks to be performed by regular users. They can be set in the XATTR space for a file in the filesystem to allow a program to perform such capabilities if run non-root. OR, users on a per user basis can be given capability access by editing/adding /etc/security/capabilities.conf.
The major use for capabilities is to let network tools, especially packet capture tools run as non-root to prevent exploits run against them from gaining root, or otherwise exploited as a SUID binary. Yes, you can use /dev/udp and /dev/tcp to open connections, but not set permissions
If setting per file/program you can check with
getcap <filename>
and you can set capabilities with
setcap <capabilities> <filename>


== References ==
== References ==
<references />
<references />
[[Category: Terminology]]
[[Category: Linux]]

Latest revision as of 14:33, 4 January 2024

Linux Regular(default) Permission

ls command witl -al option to view the permissions (or file mode) set for the contents of a directory[1]

$ ls -al /
total 2098648
drwxr-xr-x   20 root    root             4096 May 25 08:40 .
drwxr-xr-x   20 root    root             4096 May 25 08:40 ..
lrwxrwxrwx    1 root    root                7 Aug 31  2022 bin -> usr/bin
drwxr-xr-x    4 root    root             4096 May 25 09:40 boot
drwxr-xr-x   20 root    root             4820 May 25 08:37 dev
drwxr-xr-x  130 root    root            12288 May 25 09:42 etc
drwxr-xr-x    6 root    root             4096 May 15 10:36 home
lrwxrwxrwx    1 root    root                7 Aug 31  2022 lib -> usr/lib
lrwxrwxrwx    1 root    root                9 Aug 31  2022 lib32 -> usr/lib32
lrwxrwxrwx    1 root    root                9 Aug 31  2022 lib64 -> usr/lib64
lrwxrwxrwx    1 root    root               10 Aug 31  2022 libx32 -> usr/libx32
drwx------    2 root    root            16384 Aug 31  2022 lost+found
drwxr-xr-x    3 root    root             4096 Aug 31  2022 media
drwxr-xr-x    5 root    root             4096 Dec 13 10:03 mnt
drwxr-xr-x   10 root    root             4096 Apr  9 12:37 opt
dr-xr-xr-x 1264 root    root                0 May 25 08:36 proc
drwxr-xr-x   35 root    root             1160 May 25 09:26 run
lrwxrwxrwx    1 root    root                8 Aug 31  2022 sbin -> usr/sbin
drwxr-xr-x    2 root    root                0 May 25 08:37 server
drwxr-xr-x    2 root    root             4096 May 18 16:03 srv
-rw-------    1 root    root       2147483648 Aug 31  2022 swapfile
dr-xr-xr-x   13 root    root                0 May 25 08:36 sys
drwxrwxrwt   10 root    root          1441792 May 25 09:40 tmp
drwxr-xr-x   15 root    root             4096 May 18 15:36 usr
drwxr-xr-x   13 root    root             4096 Dec  5 17:31 var


linux regular permission
Type Description
SUID When the SUID bit is set on an executable file,

this means that the file will be executed with the same permissions as the owner of the executable file.

The passwd command is the best example for SUID. if we look at the file in detail

$ ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 68208 May 27  2020 /usr/bin/passwd


SUID can be set by

#chmod u+s file_name or #chmod 4755 file_name


and can be removed by

#chmod u-s file_name or #chmod 0755 file_name


SUID set files can be found by

#find / -perm /4000


Tip, Capital S as SUID flag means there is an error that you should look into

SGID SGID is similar to SUID, With the SGID bit set, any user executing the file will have same permissions as the group owner of the file.
  • If set on a file, it allows the file to be executed as the group that owns the file (similar to SUID)
  • If set on a directory, any files created in the directory will have their group ownership set to that of the directory owner


It’s benefit is in handling the directory. When SGID permission is applied to a directory, all sub directories and files created inside this directory will get the same group ownership as main directory.


A practical example of SGID is with Samba server for sharing files on your local network. It’s guaranteed that all new files will not lose the permissions desired, no matter who created it.

$ ls -ld /var/local

drwxrwsr-x 2 root staff 4096 Apr 15  2020 /var/local


SGID bit can be set by

#chmod g+s directory_name or #chmod 2755 directory_name


SGID bit can be removed by

#chmod g-s directory_name or #chmod 0755 directory_name


Or find by

find . -perm /2000

Sticky Bit The sticky bit works on the directory (Under linux, this permission does not affect individual files). With sticky bit set on a directory, all the files in the directory can only be deleted or renamed by the file owners only or the root.


This is typically used in the /tmp directory that works as the trash can of temporary files.

$ ls -ld /tmp

drwxrwxrwt 11 root root 4096 Feb 27 18:40 /tmp

sticky bit can be set by

#chmod +t directory_name  or #chmod 1755 directory_name

Sticky bit can be removed by

# chmod -t directory_name or #chmod 0755 directory_name

And find by

#find . -perm /1000


In numerical method, need to pass a fourth, preceding pre-defined special digit in our chmod command

  • Default 0, SUID = 4, SGID = 2, Sticky = 1

The syntax is: 

$ chmod X### file | directory

Linux Extended ACL

Extended ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing the base ownership and permissions. Default permissions can be set only for one owner, one group and Other users. So different permissions cannot be configured for different users and groups.


On Linux, Extended ACL shows "+" information when do $ls -al command. we can manage the ACL with "getfacl" and "setfacl" on the command line.

Linux extended acl.png

Listing access control lists

The getfacl command is used on Linux to print a complete listing of all regular permissions and access control lists permissions on a file or directory.

$ getfacl <file, directory>

# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
#The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries

Setting access control lists using setfacl

The setfacl has the following syntax,


$ setfacl [action] <what>:<user/group>:<permissions>

$ setfacl {-m, -x, -d, -b}  {u, g}:<name>:[r, w, x] <file, directory>

  • -m : (set or modify) means that you want to modify one or several ACL entries on the file or directory.
  • -x : (delete) means that you want to remove one or several ACL entries on a file or directory.
  • -d : (default) means specific type of permission assigned to a directory, that doesn’t change the permissions of the directory itself
  • -b : with -b option, you can erase all the ACLs set[2]
  • {u, g} : if you want to modify the ACL for a user or for a group.
  • name : this is an optional parameter, it can be omitted if you want to set the ACL entries for every user or for every group on your host.
  • [r, w, x] : in order to set read, write or execute permissions on the file or directory.
Example,

To set specific write permissions for a user on a file
$ setfacl -m u:user:w <file, directory>  

To set execute permissions for all users on your host
$ setfacl -m u::x <file, directory>    

To set full permissions for a specific group on your host
$ setfacl -m g:group:rwx <file, directory>

To remove a user specific entry from a file,
$ setfacl -x u:<user> <file, directory>

To remove ACL related to groups on your host
$ setfacl -x g:<group> <file, directory>

To allow rwx to accouting group for accounting folder 
$ setfacl -d -m accounting:rwx /accounting

To modify user2 be rwx, group admin rwx for myfolder
$ setfacl -m "u:user2:rwx,g:admin:rwx" myfolder

Creating defaults access control lists on directories

defaults access control lists are used to create ACL entries on a directory that will be inherited by objects in this directory like files or subdirectories. it is recommended to specify default permissions for all three categories (user, group and other)


To create default ACL entries syntax,

$ setfacl -d -m {u, g}:<name>:[r, w, x] <directory> 

For example, 

to assign read permissions to all files created in a directory,
$ setfacl -d -m u::r directory

To delete default existing access control lists on directories, use the -k flag
$ setfacl -k <directory>

To remove default ACL entries in a directory and all subdirectories, you would have to use a recursive option (-R)
$ setfacl -kR <directory>

Working with the access control lists mask

The ACL mask is different from the file creation mask (umask) and it is used in order to restrict existing ACL entries existing on a file or directory.

The ACL mask is updated every time you run a setfacl command unless you specify that you don’t want to update the mask with the -n flag.

To prevent the mask from being updated,
$ setfacl -n -m u:antoine:rwx <file, directory>

Following example show how mask is mapping to user and group[3]

# file: myfolder
# owner: user1
# group: [[test]]
user::rwx
user:user2:rwx          # effective: r-x due to mask
group::r-x
group:admin:rwx         # effective: r-x due to mask
mask::r-x               # mask effective to user and group 
other::---

Umask

The umask utility is used to control the file-creation mode mask, which determines the initial value of file permission bits for newly created files since all new file permission calculated by

new file permission = default permission & (~mask)

  • default permission on Linux - the default creation permissions are 777 for directories and only 666 for files.
  • only the file permission bits of the mask are used - see umask(2). The suid, sgid and sticky bits of the mask are ignored.

assumming that the file-creation mode mask is 027

  • 0 stands for the user permission bits not set on a newly created file
  • 2 stands for the group permission bits not set on a newly created file
  • 7 stands for the other permission bits not set on a newly created file

To display the current mask, simply invoke umask without specifying any arguments

$ umask
0027

#When the -S option, standardized by POSIX 
$ umask -S
u=rwx,g=rx,o=


To set the umask value through the umask command,

System-wide umask value can be set in /etc/profile or in the default shell configuration files (e.g. /etc/bash.bashrc) in most Linux distributions.

User specific umask value can be set in ~/.bashrc to only change your umask, however these changes will only take effect after the next login

under GUI environment like KDE, The umask value can be set via pam_umask.so or a systemd

/etc/systemd/system/user@.service.d/override.conf

[Service]
UMask=0002

pam_umask.so allows to set the system-wide umask value for both, text console and graphical environment.

pam_umask.so needs to be enabled in a configuration file that is included by both, /etc/pam.d/login and /etc/pam.d/systemd-user. Add the following line to /etc/pam.d/system-login: 

# session    optional   pam_umask.so         umask=022

File Attributes

Apart from the file mode bits that control user and group read, write and execute permissions, several file systems file attributes that enable further customization of file operations.

Extended attributes can be changed with chattr and listing them with lsattr which is included in e2fsprogs package. this page explained details how to use lsattr and chattr 

<lsattr | chattr> [+|-] [attributes] <filename>

These are a few useful attributes. Not all filesystems support every attribute.

  • a - append only: File can only be opened for appending. like i, but can only be appended.
  • c - compressed: Enable filesystem-level compression for the file.
  • i - immutable: Cannot be modified, deleted, renamed, linked to. Can only be set by root. with this bit set, the file becomes the unmovable object. No writes, not from the kernel or daemons, and not from the root user.
  • j - data journaling: Use the journal for file data writes as well as metadata.
  • m - no compression: Disable filesystem-level compression for the file.
  • A - no atime update: The file's atime will not be modified.
  • C - no copy on write: Disable copy-on-write, for filesystems that support it.

**If root cannot delete or modify some file, that file should have a and i file attributes. some virus or malware use this attributes to execute process under Linux.

Extended Attributes (xattrs)

xattr - Extended attributes are name:value pairs associated permanently with files and directories defines four extended attribute classes: security, system, trusted and user.

archlinux provides great information about xattr and capability

**unlike ACLs, xattrs do not show up anywhere but with lsattr[4]

POSIX Capabilities

POSIX 1003.1e capabilities are role/action based capabilities that that allow certain root-only tasks to be performed by regular users. They can be set in the XATTR space for a file in the filesystem to allow a program to perform such capabilities if run non-root. OR, users on a per user basis can be given capability access by editing/adding /etc/security/capabilities.conf.

The major use for capabilities is to let network tools, especially packet capture tools run as non-root to prevent exploits run against them from gaining root, or otherwise exploited as a SUID binary. Yes, you can use /dev/udp and /dev/tcp to open connections, but not set permissions

If setting per file/program you can check with

getcap <filename>

and you can set capabilities with

setcap <capabilities> <filename>

References

  1. ↑ https://wiki.archlinux.org/title/File_permissions_and_attributes
  2. ↑ https://linuxconfig.org/how-to-manage-acls-on-linux
  3. ↑ https://www.learnitguide.net/2015/12/setting-up-access-control-lists-acl-on.html
  4. ↑ https://www.linkedin.com/pulse/linux-permissions-anything-simple-jack-barber
Retrieved from "http://wiki.hpcmate.com/index.php?title=Linux_file_permission&oldid=1733"