File permissions

The permission mask is used to determine what, if any
access each level or class of user has to each
file on a Unix system. The permission mask is one of
the data elements stored in the inode table
entry for the file.
Every file has protection or permission
attributes for 3
classifications or levels of system user, i.e.
  • User (u)
  • Group (g)
  • Other (o)
These permissions are displayed using the

ls -l
command. 


Group
      <->
- rwx r-x r-x 1 bin 114688 Jun 23 1987 /bin/csh
  <->     <->
 User    Other
The permission mask is divided into three areas,
also called levels of permission. The left most
group of three permissions are those permissions
that apply to the user, or individual who
owns the file. (We refer to this individual as
the "user" rather than the "owner" because the third
field, "other" starts with the letter "o", and we
don't want to get confused.)

In this case, ownership is determined by the user
identification number assigned when the file is created.
Don't worry about the user identification number at this
point, we'll look closely at it when we look at how your
user record is created and stored. This number is the UID
or "User Identification Number", the third field
in /etc/passwd.
The second three permissions are those assigned to all
the individuals who share the same group identification
number as the user. This is the fourth field in /etc/passwd.
The third set of three permissions are those assigned to the
"other" users. Anyone who has a valid login ID on the system,
but is not the user of the file, nor in the users group is
considered "other".
In other words, the nine bit permission mask is divided into
three, three bit permission sub masks one for user,
one for group, and one for everyone else other.
Each permission sub mask, or level of permission, is
divided into three different individual permissions. The
left most permission r allows the file to be read,
the center permission w allows the file to be written,
and the right most permission in each level x allows
the file to be executed.
The actual meaning of the write and execute permissions
have slightly different meaning depending on whether the file
is a regular file or a directory. In the case of a regular file
writing simply means that the contents of the file can be modified.
Executing a regular file means that the command line interpreter
will attempt to run the text contained within the file as if it were
instructions.
In the case of a directory file, writing means that the contents of
the directory can be changed, files added or deleted. Execute
permission on a directory file allows the use of file matching
meta- characters to search within the directory. If you think
about it, writing is actually the same for a directory or
regular file because both are simply ASCII files.
The figure below shows the permissions mask:


 
 
  8 7 6  5 4 3    2 1 0
|-------|-------|------|
| USER    GROUP  OTHER |
| r w x | r w x | r w x|
|----------------------|



There are two different methods a user
may employ to alter the permission mask on
a file.

  1.  The owner of a file may change the permission
    bits using an octal representation of the
    required permissions. If you choose this method
    remember that you must specify the whole
    permissions mask    , (all 9 bits),
    not just one individual permission.
    You will need to use the octal representation
    for each of the three different levels of
    permission. That means the permission mask you
    will specify will be 3 octal numbers.
    Since each octal number can be represented by 3
    bits, each bit can represent one permission.
    Each bit position corresponds to one permission
    value. A three bit number has the following
    positional values:
    4 2 1
    read write execute


    The following table shows each of the 7 possible
    permission combinations for one of the three levels
    of permissions. Remember, you will need
    to use three (3) octal numbers.
    OctalBinaryPermission
    0000no permissions
    1001execute
    2010write
    3011write + execute
    4100read
    5101read + execute
    6110read + write
    7111read + write + execute

    The code example below shows how the octal values can
    be used to modify the permissions mask on a file. For
    this example, please note that both ringo and lennon
    are in the same group.
     
    ringo % chmod 710 /usr/ringo
ringo % ls -lg /usr/ringo
drwx--x--- 1 ringo beatles 512 Nov 24 18:00 /ringo
ringo % chmod 740 /usr/ringo/help
ringo % ls -lg /usr/ringo/help
-rwxr----- 1 ringo beatles 1511 Nov 24 18:21 /usr/ringo/help
lennon % cp ~ringo/help .
lennon %
    Refer to the table above to
    interpet the octal values.

    The first command gives full permission to the
    directories owner (ringo), execute permission
    to the group and no
    permissions to anyone not a member of the owners
    group (beatles). Members of the
    owners group may access a directory (usually for
    a known filename) but may not list the files in
    owners directory.
    The second command gives full permission to the
    directories owner (ringo)allows group
    members (e.g. lennon) and the
    owner to read the file but denys any access
    to "other".

  2. Alternatively symbolic notation may be used,
    e.g. to grant or deny read, write, or execute permission
    to the user, group and others permission masks.

    Usually this method is used to modify only one (1)
    permission, for one level. For example, giving
    execute permission to the owner of a file, or removing
    read permission from the group.
    The table below shows the three levels of
    permission, and the three permissions for each level.
    Level Permissions
    u - user r - read   w - write   e
    - execute
    g - group r - read   w - write   e
    - execute
    o - other r - read   w - write   e
    - execute
    In the following code snippet, the first line grants read
    permission for other, to the file     john/sgtpepper


    The second line removes write access from both the group
    and other for the same file.     
    lennon % chmod o+r john/sgtpepper
lennon % chmod go-w john/sgtpepper


    Notice that in each case, the remaining permissions for the file
    were not changed     . Normally, you would use this second method to
    alter one or two permissions, and the first method, octal, to change
    several permissions at one time.
Security of file contents (as opposed to
access) can be achieved using the crypt
program or other encryption tools like
pgp
or the Unix crypt

command. (Consult your system documentation man crypt




[ ]

Unix security

Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.
Design concepts
Permissions
A core security feature in these systems is the permissions system. All files in a typical Unix-style filesystem have permissions set enabling different access to a file.
Permissions on a file are commonly set using the chmod command and seen through the ls command. For example:
-r-xr-xr-x 1 root wheel 745720 Sep 8 2002 /bin/sh
Unix permissions permit different users access to a file. Different user groups have different permissions on a file.
More advanced Unix filesystems include the Access Control List concept which allows permissions to be granted to multiple users or groups. An Access Control List may be used to grant permission to additional individual users or groups. For example:
/pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:sue:rwx,g::r-x,m::rwx,o::r-x]
In this example, which is from the chacl command on the Linux operating system, the user sue is granted write permission to the /pvr directory.
User groups
Users under Unix style operating systems often belong to managed groups with specific access permissions. This enables users to be grouped by the level of access they have to this system. Many Unix implementations add an additional layer of security by requiring that a user be a member of the wheel user privileges group in order to access the su command.[1]
Issues
Most Unix and Unix-like systems have an account or group which enables a user to exact complete control over the system, often known as a root account. If access to this account is gained by an unwanted user, this results in a complete breach of the system. A root account however is necessary for administrative purposes, and for the above security reasons the root account is seldom used for day to day purposes (the sudo program is more commonly used), so usage of the root account can be more closely monitored.
Root access "as it should be" can be visualised by those familiar with the Superman stories using the following analogy:
Using a root account is rather like being Superman; an administrator's regular user is more like Clark Kent. Clark Kent becomes Superman for only as long as necessary, in order to save people. He then reverts to his "disguise". Root access should be used in the same fashion. The Clark Kent disguise doesn't really restrict him though, as he is still able to use his super powers. This is analogous to using the sudo program.
User and administrative techniques
Unix has many tools that can improve security if used properly by users and administrators.
Passwords
Selecting a strong password and guarding it properly are probably the most important things a user can do to improve Unix security. In Unix systems, the essential information about users is stored under the file /etc/passwd. This file keeps track of the users registered in the system and their main definitions. Passwords, or more correctly, the hash of the password, can also be stored in the same place. The entries in /etc/passwd occupy exactly one line each, and have the following form:
nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin
An example would be:
xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:José Carlos D. S. Saraiva:/home/xfze:/bin/bash
Since all users must have read access to this file, in order for the system to check the login password, one security issue was raised: anyone could have read the file and retrieve the password hashes of other users. To solve this problem, the file /etc/shadow was created to store the password hashes, with only root having read access. Under password shadowing, the /etc/passwd the 2nd field (password hash) is replaced by an 'x' which tells the system to retrieve the corresponding user's password via the /etc/shadow file.
The /etc/shadow file usually only contains the first two fields:
xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::
The remaining fields in the /etc/shadow file include:
1. The minimum number of days between password changes
2. The maximum number of days until the password must be changed
3. The number of days of warning given before the password must be changed
4. The number of days after the password must be changed when the account becomes unusable
5. The date (expressed as the number of days since January 1st, 1970) when the account is expired
These fields may be used to improve Unix security by enforcing a password security policy.
Users and accounts
Administrators should delete old accounts promptly.
• su, sudo, ssh only, no remote root logins
Software Maintenance
Patching
Operating systems, like all software, may contain bugs in need of fixing or may be enhanced with the addition of new features. Patching the operating system in a secure manner requires that the software come from a trustworthy source and not have been altered since it was packaged. Common methods for verifying that operating system patches have not been altered include the use of cryptographic hash, such as an MD5 based checksum, or the use of read-only media.
From a security standpoint, the specific packaging method, such as the RPM Package Manager format originally from Red Hat Linux is not as important as the use of features which ensure the integrity of the patch itself.
Source Distributions
Source distributions include the ability to examine the code for suspicious content. The drawback, absent an accompanying cryptographic hash value, is that the user must be able to perform a security analysis of the code themselves.
RPM Packages
Linux distributions which use the RPM Package Manager format for providing base functionality and software updates make use of MD5 and GPG to ensure content integrity. The hash values are packaged with the RPM file and verified when the package is installed.
Debian Packages
Linux distributions which use the Debian .deb package format for providing base functionality and software updates make use of GPG signatures to ensure content integrity. A signature is computed when the package is constructed and verified later when the package is installed.
Other vendors and distributions
Regardless of the vendor or distribution, all software distributions should provide a mechanism for verifying that the software is legitimate and has not been modified since it was originally packaged.
Services
Unnecessary system software should not be installed or configured on a system. Software which is no longer required should be removed completely, if possible.
• Identify what services are running
o netstat -na
o lsof
o nmap
o sockstat -4 (FreeBSD)
The commands inetd and xinetd act as super-servers for a variety of network protocols such as rlogin, telnet and ftp.
Turning off unnecessary services
• using chkconfig on Red Hat Linux
• using /etc/rc.conf and /usr/local/etc/rc.d on FreeBSD (mention /etc/rc.local)
• using rc-update on Gentoo Linux
This approach is usually called proactive security. There are some operating systems which are secure by default. Amongst others, the free BSD flavours (FreeBSD, NetBSD, and OpenBSD) are proactively secure. For example, the output of netstat on a NetBSD 3.0 workstation clearly outlines this technique:
$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost.smtp *.* LISTEN
tcp 0 0 *.ssh *.* LISTEN
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp6 0 0 localhost.smtp *.* LISTEN
tcp6 0 0 *.ssh *.* LISTEN
Active UNIX domain sockets
Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr
c0d10d80 dgram 0 0 0 c0cd8680 0 c0cb7000 -> /var/run/log
c0cb7000 dgram 0 0 0 c0cd8680 0 0 -> /var/run/log
c0cd8680 dgram 0 0 cb9639e8 0 c0d10d80 0 /var/run/log
The following example from a BSD system
$ sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 569 4 tcp localhost.smtp *.*
root sshd 593 4 tcp *.ssh *.*
Shows that on this machine only the SSH service is listening to the public network interface of the computer. sendmail is listening to the loopback interface only. Access to a service may be further restricted by using a firewall.
File Systems
File system security
Main article: File system permissions
File system security within UNIX and Unix-like systems is based on 9 permission bits, set user and group ID bits, and the sticky bit, for a total of 12 bits. These permissions apply almost equally to all filesystem objects such as files, directories and devices.
The 9 permission bits are divided into three groups of three bits each. The first group describes the permissions of the file owner, the second group describes the permissions of a group associated with the file owner or the directory containing the file, and the third group describes the permissions associated with any process which does not have the same user ID as the file. Each group of three bits contains a bit indicating the read, write or execute access is granted. In the case of directories, execute access is interpreted as the permission to perform a filename lookup within the directory.
The set user ID and set group ID bits, commonly abbreviated set-UID and set-GID respectively, are used to change the identity of the process which executes a file having either or both of those bits set. A file having the set-UID permission bit set will cause a process which executes that file to temporarily switch the effective user ID to that of the file owner. A file having the set-GID permission bit set will cause a process which executes that file to temporarily switch the effective group ID to that of the file group. A process may then alternate between the effective user or group ID which it inherited from the file and the real user or group ID which it inherited when the user logged on to the system. This provides a mechanism by which a process may limit the access rights it possesses to those code regions which require those access rights. This is a form of a security technique known as privilege separation and improves program security by limiting the unintended or undesirable actions of a processes.
A directory having the set-GID permission bit set will cause a newly created file to have an initial file group value equal to the file group of the directory. This provides a mechanism whereby a subsystem, such as the system's mail subsystem, can create files which have a common file group value so that set-GID processes within that subsystem are then able to read or write the file.
The sticky bit, formally known as the save text on swap bit, derives its name from its original purpose. Originally the sticky bit caused a process's initial memory image to be stored as a contiguous image on the disk drive which was used to store real memory pages when they were not in use. This improved the performance of commonly executed commands by making the initial memory image readily available. Modern UNIX systems no longer perform that function when the bit is set, but the name has been preserved nonetheless. In the case of files, the sticky-bit may be used by the system to indicate the style of file locking to be performed. In the case of directories, the sticky bit prevents any process, other than one which has super-user privileges or one having an effective user ID of the file owner, from deleting a file within that directory. The sticky bit is most commonly used on publicly writable directories, such as the various temporary working space directories on the system.
Root squash
Root squash[2][3] is reduction of the access rights for the remote superuser (root) when using identity authentication (local user is the same as remote user). It is primarily the feature of NFS but potentially may be available on other systems as well.
This problem arises when some remote file system is shared by multiple users. These users belong to one or multiple groups. In Unix, every file and folder normally has the separate permissions (read, write, execute) for the owner (normally the creator of the file), for the group to that the owner belongs and for the "world" (all other users). This allows to restrict write and read access only to the authorized users while in general NFS server must also be protected by firewall.
Superuser has more rights than the ordinary user, being able to change the file ownership, set arbitrary permissions and access all protected content. Even users that do need to have root access to they individual workstations may not be authorized for the similar actions on a shared file system. Root squash reduces rights of the remote root, making one no longer superuser. On UNIX like systems, root squash option can be turned on and off in /etc/exports file on a server side.
After implementing the root squash, the authorized superuser performs restricted actions after logging in into NFS server directly and not just by mounting the exported NFS folder.
SELinux
SELinux is the set of kernel extensions to control access more presicely, strictly defining both if and how files, folders, network ports and other resources can be accessed by the confined process. This system is mostly used to restrict processes (database, server) rather than human users. It can also limit processes that run as root. Other distributions use comparable alternatives like AppArmor.
Viruses and Virus Scanners
Unix-like operating systems are immune to most Microsoft Windows viruses because binaries created to run on Windows generally won't run on other platforms. However, many Unix like installations provide file storage services to Microsoft Windows clients, such as through the use of Samba software, and may unintentionally become a repository for viruses stored by users. It is common for Unix servers to act as Mail Transfer Agents consequently email virus scanning is often installed. The ClamAV virus scanner is available in source code form and may be used to scan Unix file systems for viruses which infect other operating systems.
There are viruses and worms that target Unix-like operating systems. In fact, the first computer worm -- the Morris worm -- targeted Unix systems.
Firewalls
Network firewall protects systems and networks from network threats which exist on the opposite side of the firewall. Firewalls can block access to strictly internal services, unwanted users and in some cases filter network traffic by content.
iptables
iptables is the current user interface for interacting with Linux kernel netfilter functionality. It replaced ipchains. Other Unix like operating systems may provide their own native functionality and other open source firewall products exist. More detailed information about iptables is contained elsewhere. A brief discussion is contained here in order to describe how iptables may be used to configure a Linux firewall.
netfilter provides a state-full packet filter which can be configured according to network interface, protocol, source and/or destination address, source and/or destination port and the state of the packet. A network packet traverses several chains between the time it is received by a network interface and the time it is accepted by the host or forwarded to another host. The common chains are INPUT, OUTPUT and FORWARD. The INPUT chain is traversed for all packets as they are received by a network interface, regardless of whether they are to be accepted by the host or forwarded to another host. The OUTPUT chain is traversed for all packets as they are transmitted by a network interface. The FORWARD chain is traversed for those packets are being routed through the host from one network interface to another, such as is the case for a multi-homed system (a system with more than one physical network interface).
Each of the built-in chains has a default policy which defines what action is taken for a packet which reaches the end of the chain. Packet traversal ends when a rule matches the packet and has an action of ACCEPT, DROP, REJECT or RETURN.
The simplest iptables firewall consists of rules for each desired service, followed by a rule which indicates that any packets which reach this rule are dropped. A system which only permitted, for example, incoming email traffic would have a rule which accepted connections on the SMTP port, and then dropped others. A rule would be required which indicated that all established connections were also permitted so that outgoing connections would receive responses from other systems.
INPUT chain
The following example shows a simple packet filter for the INPUT chain for the above described example:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere state ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
0 0 LOG all -- any any anywhere anywhere LOG level warning
0 0 DROP all -- any any anywhere anywhere
The addition of an explicit DROP action ensures that the packets are discarded should the default policy of the INPUT chain accidentally be changed to ACCEPT.
OUTPUT chain
There is less need for an OUTPUT chain and the default policy of the OUTPUT chain can safely be set to ACCEPT. In some instances it may be desirable for a firewall to limit certain outgoing connections to a certain set of approved systems. This is known as egress filtering and may be used to prevent viruses within the firewall from escaping to other systems. For example, it may be the policy of a network to limit outgoing email connections to a single authorized email servers as a way of combating e-mail spam. This could be achieved by the following example:
Chain OUTPUT (policy ACCEPT)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- any any !server anywhere tcp dpt:smtp
There is no need to include any other rules in this example as the default policy for the OUTPUT chain is ACCEPT. Note also that this rule assumes that the host which is acting as the firewall will not be sending email itself, such as to the email server. This is a good assumption as typically a firewall system contains the minimal amount of system code needed to act as a firewall.
A more restrictive OUTPUT chain would contain permissive (ACCEPT) entries for those services which may be accessed outside the firewall and then a restrictive (DROP) policy for the chain itself.

Filesystem permissions

Most current file systems have methods of administering permissions or access rights to specific users and groups of users. These systems control the ability of the users affected to view or make changes to the contents of the filesystem.
Differences between operating systems
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and all Mac OS X versions, have a simple system for managing individual file permissions, which in this article are called "traditional Unix permissions". Most of these systems also support some kind of access control lists, either proprietary (old HP-UX ACLs, for example), or POSIX.1e ACLs, based on an early POSIX draft that was abandoned, or NFSv4 ACLs, which are part of the NFSv4 standard.
DOS variants (including MS-DOS, Windows 95, Windows 98, and Windows Me) do not have permissions, only file attributes. There is a read-only attribute (R), which can be set or unset on a file by any user or program, and therefore does not prevent him/her from changing/deleting the file. There is no permission in these systems which would keep a user from reading a file.
OpenVMS (a.k.a. VMS), as well as Microsoft Windows NT and its derivatives (including Windows 2000 and Windows XP), use access control lists (ACLs)[1] to administer a more complex and varied set of permissions. OpenVMS also uses a permission scheme similar to that of Unix, but more complex. There are four categories(System, Owner, Group, and World) and four types of access permissions (Read, Write, Execute, and Delete). The categories are not mutually disjoint: World includes Group which in turn includes Owner. The System category independently includes system users (similar to superusers in Unix).[2]
Classic Mac OSes are similar to DOS variants and DOS-based Windows: they do not support permissions, but only a "Protected" file attribute.
The AmigaOS Filesystem, AmigaDOS supports a relatively advanced permissions system, for a single-user OS. In AmigaOS 1.x, files had Archive, Read, Write, Execute and Delete (collectively known as ARWED) permissions/flags. In AmigaOS 2.x and higher, additional Hold, Script, and Pure permissions/flags were added.
Mac OS X versions 10.3 ("Panther") and prior use POSIX-compliant permissions. Mac OS X, beginning with version 10.4 ("Tiger"), also support the use of NFSv4 ACLs. They still support "traditional Unix permissions" as used in previous versions of Mac OS X, and the Apple Mac OS X Server version 10.4+ File Services Administration Manual recommends using only traditional Unix permissions if possible. It also still supports the Mac OS Classic's "Protected" attribute.
Solaris ACL support depends on the filesystem being used; older UFS filesystem supports POSIX.1e ACLs, while ZFS supports only NFSv4 ACLs.[3]
Linux supports POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3 filesystem.[4]
FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.[5]
IBM z/OS implements file security via RACF (Resource Access Control Facility)[6]
Traditional Unix permissions
Permissions on Unix-like systems are managed in three distinct classes. These classes are known as user, group, and others. In effect, Unix permissions are a simplified form of access control lists (ACLs).
When a new file is created on a Unix-like system, its permissions are determined from the umask of the process that created it.
Classes
Files and directories are owned by a user. The owner determines the file's owner class. Distinct permissions apply to the owner.
Files and directories are assigned a group, which define the file's group class. Distinct permissions apply to members of the file's group members. The owner doesn't need to be a member of the file's group.
Users who are not the owner, nor a member of the group, comprise a file's others class. Distinct permissions apply to others.
The effective permissions are determined based on the user's class. For example, the user who is the owner of the file will have the permissions given to the owner class regardless of the permissions assigned to the group class or others class.
Permissions
There are three specific permissions on Unix-like systems that apply to each class:
• The read permission, which grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory (but not to find out any further information about them such as contents, file type, size, ownership, permissions, etc.)
• The write permission, which grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files.
• The execute permission, which grants the ability to execute a file. This permission must be set for executable binaries (for example, a compiled C++ program) or shell scripts (for example, a Perl program) in order to allow the operating system to run them. When set for a directory, this permission grants the ability to traverse its tree in order to access files or subdirectories, but not see the content of files inside the directory (unless read is set).
The effect of setting the permissions on a directory (rather than a file) is "one of the most frequently misunderstood file permission issues"[7].
When a permission is not set, the rights it would grant are denied. Unlike ACL-based systems, permissions on a Unix-like system are not inherited. Files created within a directory will not necessarily have the same permissions as that directory. The permissions to be assigned are determined using umasks.

Notation of traditional Unix permissions
Symbolic notation
There are many ways by which Unix permission schemes are represented. The most common form is symbolic notation.
Three groups of three
first what the owner can do
second what the group members can do
third what other users can do
The triplet
first r: readable.
second w: writable.
third x: executable.
s or t: executable and setuid/setgid/sticky.
S or T: setuid/setgid or sticky, but not executable.
The first character indicates the file type:
• - denotes a regular file
• d denotes a directory
• b denotes a block special file
• c denotes a character special file
• l denotes a symbolic link
• p denotes a named pipe
• s denotes a domain socket
Each class of permissions is represented by three characters. The first set of characters represents the user class. The second set represents the group class. The third and final set of three characters represents the others class.
Each of the three characters represent the read, write, and execute permissions respectively:
• r if the read bit is set, - if it is not.
• w if the write bit is set, - if it is not.
• x if the execute bit is set, - if it is not.
The following are some examples of symbolic notation:
• -rwxr-xr-x for a regular file whose user class has full permissions and whose group and others classes have only the read and execute permissions.
• crw-rw-r-- for a character special file whose user and group classes have the read and write permissions and whose others class has only the read permission.
• dr-x------ for a directory whose user class has read and execute permissions and whose group and others classes have no permissions.

Octal notation
Another common method for representing Unix permissions is octal notation. Octal notation consists of a three- or four-digit base-8 value.
With three-digit octal notation, each numeral represents a different component of the permission set: user class, group class, and "others" class respectively.
Each of these digits is the sum of its component bits (see also Binary numeral system). As a result, specific bits add to the sum as it is represented by a numeral:
• The read bit adds 4 to its total (in binary 100),
• The write bit adds 2 to its total (in binary 010), and
• The execute bit adds 1 to its total (in binary 001).
These values never produce ambiguous combinations; each sum represents a specific set of permissions.
These are the examples from the Symbolic notation section given in octal notation:
• "-rwxr-xr-x" would be represented as 755 in three-digit octal.
• "-rw-rw-r--" would be represented as 664 in three-digit octal.
• "-r-x------" would be represented as 500 in three-digit octal.
Here is a summary of the meanings for individual octal digit values:
0 --- no permission
1 --x execute
2 -w- write
3 -wx write and execute
4 r-- read
5 r-x read and execute
6 rw- read and write
7 rwx read, write and execute
Note the similarity to binary counting (starting at the right and going left):
0: 000
1: 001
2: 010
3: 011
4: 100
5: 101
6: 110
7: 111
Octal digit values can be added together to make Symbolic Notations:
(4=r)+(1=x) == (5=r-x)
(4=r)+(2=w) == (6=rw-)
(4=r)+(2=w)+(1=x) == (7=rwx)
Here is a summary showing which octal digits affect permissions for user, group, and other:
• UGO = User, Group, Other
• 777 = "-rwxrwxrwx" = rwx for all
• 754 = "-rwxr-xr--" = rwx for owner, r-x for group, r-- for other
• 124 = "--x-w-r--" = x for owner, w for group, r for other

Listing Permissions
ls -l prints symbolic notation for files and directories.
stat -c '%n %a %A' can be used to print out octal notation.
User private group
Some systems diverge from the traditional POSIX-model of users and groups, by creating a new group – a "user private group" – for each user. The "user private group" scheme can be preferred for a variety of reasons[8][9][10] including using a umask of 002 and not having every "user" able to write to newly created files. In this case however, no other users must be added to the "user private group" or they will have write-permission on all files.
Subscribe to: Posts (Atom)

Saturday 30 July 2011

File permissions

The permission mask is used to determine what, if any
access each level or class of user has to each
file on a Unix system. The permission mask is one of
the data elements stored in the inode table
entry for the file.
Every file has protection or permission
attributes for 3
classifications or levels of system user, i.e.
  • User (u)
  • Group (g)
  • Other (o)
These permissions are displayed using the

ls -l
command. 


Group
      <->
- rwx r-x r-x 1 bin 114688 Jun 23 1987 /bin/csh
  <->     <->
 User    Other
The permission mask is divided into three areas,
also called levels of permission. The left most
group of three permissions are those permissions
that apply to the user, or individual who
owns the file. (We refer to this individual as
the "user" rather than the "owner" because the third
field, "other" starts with the letter "o", and we
don't want to get confused.)

In this case, ownership is determined by the user
identification number assigned when the file is created.
Don't worry about the user identification number at this
point, we'll look closely at it when we look at how your
user record is created and stored. This number is the UID
or "User Identification Number", the third field
in /etc/passwd.
The second three permissions are those assigned to all
the individuals who share the same group identification
number as the user. This is the fourth field in /etc/passwd.
The third set of three permissions are those assigned to the
"other" users. Anyone who has a valid login ID on the system,
but is not the user of the file, nor in the users group is
considered "other".
In other words, the nine bit permission mask is divided into
three, three bit permission sub masks one for user,
one for group, and one for everyone else other.
Each permission sub mask, or level of permission, is
divided into three different individual permissions. The
left most permission r allows the file to be read,
the center permission w allows the file to be written,
and the right most permission in each level x allows
the file to be executed.
The actual meaning of the write and execute permissions
have slightly different meaning depending on whether the file
is a regular file or a directory. In the case of a regular file
writing simply means that the contents of the file can be modified.
Executing a regular file means that the command line interpreter
will attempt to run the text contained within the file as if it were
instructions.
In the case of a directory file, writing means that the contents of
the directory can be changed, files added or deleted. Execute
permission on a directory file allows the use of file matching
meta- characters to search within the directory. If you think
about it, writing is actually the same for a directory or
regular file because both are simply ASCII files.
The figure below shows the permissions mask:


 
 
  8 7 6  5 4 3    2 1 0
|-------|-------|------|
| USER    GROUP  OTHER |
| r w x | r w x | r w x|
|----------------------|



There are two different methods a user
may employ to alter the permission mask on
a file.

  1.  The owner of a file may change the permission
    bits using an octal representation of the
    required permissions. If you choose this method
    remember that you must specify the whole
    permissions mask    , (all 9 bits),
    not just one individual permission.
    You will need to use the octal representation
    for each of the three different levels of
    permission. That means the permission mask you
    will specify will be 3 octal numbers.
    Since each octal number can be represented by 3
    bits, each bit can represent one permission.
    Each bit position corresponds to one permission
    value. A three bit number has the following
    positional values:
    4 2 1
    read write execute


    The following table shows each of the 7 possible
    permission combinations for one of the three levels
    of permissions. Remember, you will need
    to use three (3) octal numbers.
    OctalBinaryPermission
    0000no permissions
    1001execute
    2010write
    3011write + execute
    4100read
    5101read + execute
    6110read + write
    7111read + write + execute

    The code example below shows how the octal values can
    be used to modify the permissions mask on a file. For
    this example, please note that both ringo and lennon
    are in the same group.
     
    ringo % chmod 710 /usr/ringo
ringo % ls -lg /usr/ringo
drwx--x--- 1 ringo beatles 512 Nov 24 18:00 /ringo
ringo % chmod 740 /usr/ringo/help
ringo % ls -lg /usr/ringo/help
-rwxr----- 1 ringo beatles 1511 Nov 24 18:21 /usr/ringo/help
lennon % cp ~ringo/help .
lennon %
    Refer to the table above to
    interpet the octal values.

    The first command gives full permission to the
    directories owner (ringo), execute permission
    to the group and no
    permissions to anyone not a member of the owners
    group (beatles). Members of the
    owners group may access a directory (usually for
    a known filename) but may not list the files in
    owners directory.
    The second command gives full permission to the
    directories owner (ringo)allows group
    members (e.g. lennon) and the
    owner to read the file but denys any access
    to "other".

  2. Alternatively symbolic notation may be used,
    e.g. to grant or deny read, write, or execute permission
    to the user, group and others permission masks.

    Usually this method is used to modify only one (1)
    permission, for one level. For example, giving
    execute permission to the owner of a file, or removing
    read permission from the group.
    The table below shows the three levels of
    permission, and the three permissions for each level.
    Level Permissions
    u - user r - read   w - write   e
    - execute
    g - group r - read   w - write   e
    - execute
    o - other r - read   w - write   e
    - execute
    In the following code snippet, the first line grants read
    permission for other, to the file     john/sgtpepper


    The second line removes write access from both the group
    and other for the same file.     
    lennon % chmod o+r john/sgtpepper
lennon % chmod go-w john/sgtpepper


    Notice that in each case, the remaining permissions for the file
    were not changed     . Normally, you would use this second method to
    alter one or two permissions, and the first method, octal, to change
    several permissions at one time.
Security of file contents (as opposed to
access) can be achieved using the crypt
program or other encryption tools like
pgp
or the Unix crypt

command. (Consult your system documentation man crypt




[ ]
Posted by at

Unix security

Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.
Design concepts
Permissions
A core security feature in these systems is the permissions system. All files in a typical Unix-style filesystem have permissions set enabling different access to a file.
Permissions on a file are commonly set using the chmod command and seen through the ls command. For example:
-r-xr-xr-x 1 root wheel 745720 Sep 8 2002 /bin/sh
Unix permissions permit different users access to a file. Different user groups have different permissions on a file.
More advanced Unix filesystems include the Access Control List concept which allows permissions to be granted to multiple users or groups. An Access Control List may be used to grant permission to additional individual users or groups. For example:
/pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:sue:rwx,g::r-x,m::rwx,o::r-x]
In this example, which is from the chacl command on the Linux operating system, the user sue is granted write permission to the /pvr directory.
User groups
Users under Unix style operating systems often belong to managed groups with specific access permissions. This enables users to be grouped by the level of access they have to this system. Many Unix implementations add an additional layer of security by requiring that a user be a member of the wheel user privileges group in order to access the su command.[1]
Issues
Most Unix and Unix-like systems have an account or group which enables a user to exact complete control over the system, often known as a root account. If access to this account is gained by an unwanted user, this results in a complete breach of the system. A root account however is necessary for administrative purposes, and for the above security reasons the root account is seldom used for day to day purposes (the sudo program is more commonly used), so usage of the root account can be more closely monitored.
Root access "as it should be" can be visualised by those familiar with the Superman stories using the following analogy:
Using a root account is rather like being Superman; an administrator's regular user is more like Clark Kent. Clark Kent becomes Superman for only as long as necessary, in order to save people. He then reverts to his "disguise". Root access should be used in the same fashion. The Clark Kent disguise doesn't really restrict him though, as he is still able to use his super powers. This is analogous to using the sudo program.
User and administrative techniques
Unix has many tools that can improve security if used properly by users and administrators.
Passwords
Selecting a strong password and guarding it properly are probably the most important things a user can do to improve Unix security. In Unix systems, the essential information about users is stored under the file /etc/passwd. This file keeps track of the users registered in the system and their main definitions. Passwords, or more correctly, the hash of the password, can also be stored in the same place. The entries in /etc/passwd occupy exactly one line each, and have the following form:
nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin
An example would be:
xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:José Carlos D. S. Saraiva:/home/xfze:/bin/bash
Since all users must have read access to this file, in order for the system to check the login password, one security issue was raised: anyone could have read the file and retrieve the password hashes of other users. To solve this problem, the file /etc/shadow was created to store the password hashes, with only root having read access. Under password shadowing, the /etc/passwd the 2nd field (password hash) is replaced by an 'x' which tells the system to retrieve the corresponding user's password via the /etc/shadow file.
The /etc/shadow file usually only contains the first two fields:
xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::
The remaining fields in the /etc/shadow file include:
1. The minimum number of days between password changes
2. The maximum number of days until the password must be changed
3. The number of days of warning given before the password must be changed
4. The number of days after the password must be changed when the account becomes unusable
5. The date (expressed as the number of days since January 1st, 1970) when the account is expired
These fields may be used to improve Unix security by enforcing a password security policy.
Users and accounts
Administrators should delete old accounts promptly.
• su, sudo, ssh only, no remote root logins
Software Maintenance
Patching
Operating systems, like all software, may contain bugs in need of fixing or may be enhanced with the addition of new features. Patching the operating system in a secure manner requires that the software come from a trustworthy source and not have been altered since it was packaged. Common methods for verifying that operating system patches have not been altered include the use of cryptographic hash, such as an MD5 based checksum, or the use of read-only media.
From a security standpoint, the specific packaging method, such as the RPM Package Manager format originally from Red Hat Linux is not as important as the use of features which ensure the integrity of the patch itself.
Source Distributions
Source distributions include the ability to examine the code for suspicious content. The drawback, absent an accompanying cryptographic hash value, is that the user must be able to perform a security analysis of the code themselves.
RPM Packages
Linux distributions which use the RPM Package Manager format for providing base functionality and software updates make use of MD5 and GPG to ensure content integrity. The hash values are packaged with the RPM file and verified when the package is installed.
Debian Packages
Linux distributions which use the Debian .deb package format for providing base functionality and software updates make use of GPG signatures to ensure content integrity. A signature is computed when the package is constructed and verified later when the package is installed.
Other vendors and distributions
Regardless of the vendor or distribution, all software distributions should provide a mechanism for verifying that the software is legitimate and has not been modified since it was originally packaged.
Services
Unnecessary system software should not be installed or configured on a system. Software which is no longer required should be removed completely, if possible.
• Identify what services are running
o netstat -na
o lsof
o nmap
o sockstat -4 (FreeBSD)
The commands inetd and xinetd act as super-servers for a variety of network protocols such as rlogin, telnet and ftp.
Turning off unnecessary services
• using chkconfig on Red Hat Linux
• using /etc/rc.conf and /usr/local/etc/rc.d on FreeBSD (mention /etc/rc.local)
• using rc-update on Gentoo Linux
This approach is usually called proactive security. There are some operating systems which are secure by default. Amongst others, the free BSD flavours (FreeBSD, NetBSD, and OpenBSD) are proactively secure. For example, the output of netstat on a NetBSD 3.0 workstation clearly outlines this technique:
$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost.smtp *.* LISTEN
tcp 0 0 *.ssh *.* LISTEN
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp6 0 0 localhost.smtp *.* LISTEN
tcp6 0 0 *.ssh *.* LISTEN
Active UNIX domain sockets
Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr
c0d10d80 dgram 0 0 0 c0cd8680 0 c0cb7000 -> /var/run/log
c0cb7000 dgram 0 0 0 c0cd8680 0 0 -> /var/run/log
c0cd8680 dgram 0 0 cb9639e8 0 c0d10d80 0 /var/run/log
The following example from a BSD system
$ sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 569 4 tcp localhost.smtp *.*
root sshd 593 4 tcp *.ssh *.*
Shows that on this machine only the SSH service is listening to the public network interface of the computer. sendmail is listening to the loopback interface only. Access to a service may be further restricted by using a firewall.
File Systems
File system security
Main article: File system permissions
File system security within UNIX and Unix-like systems is based on 9 permission bits, set user and group ID bits, and the sticky bit, for a total of 12 bits. These permissions apply almost equally to all filesystem objects such as files, directories and devices.
The 9 permission bits are divided into three groups of three bits each. The first group describes the permissions of the file owner, the second group describes the permissions of a group associated with the file owner or the directory containing the file, and the third group describes the permissions associated with any process which does not have the same user ID as the file. Each group of three bits contains a bit indicating the read, write or execute access is granted. In the case of directories, execute access is interpreted as the permission to perform a filename lookup within the directory.
The set user ID and set group ID bits, commonly abbreviated set-UID and set-GID respectively, are used to change the identity of the process which executes a file having either or both of those bits set. A file having the set-UID permission bit set will cause a process which executes that file to temporarily switch the effective user ID to that of the file owner. A file having the set-GID permission bit set will cause a process which executes that file to temporarily switch the effective group ID to that of the file group. A process may then alternate between the effective user or group ID which it inherited from the file and the real user or group ID which it inherited when the user logged on to the system. This provides a mechanism by which a process may limit the access rights it possesses to those code regions which require those access rights. This is a form of a security technique known as privilege separation and improves program security by limiting the unintended or undesirable actions of a processes.
A directory having the set-GID permission bit set will cause a newly created file to have an initial file group value equal to the file group of the directory. This provides a mechanism whereby a subsystem, such as the system's mail subsystem, can create files which have a common file group value so that set-GID processes within that subsystem are then able to read or write the file.
The sticky bit, formally known as the save text on swap bit, derives its name from its original purpose. Originally the sticky bit caused a process's initial memory image to be stored as a contiguous image on the disk drive which was used to store real memory pages when they were not in use. This improved the performance of commonly executed commands by making the initial memory image readily available. Modern UNIX systems no longer perform that function when the bit is set, but the name has been preserved nonetheless. In the case of files, the sticky-bit may be used by the system to indicate the style of file locking to be performed. In the case of directories, the sticky bit prevents any process, other than one which has super-user privileges or one having an effective user ID of the file owner, from deleting a file within that directory. The sticky bit is most commonly used on publicly writable directories, such as the various temporary working space directories on the system.
Root squash
Root squash[2][3] is reduction of the access rights for the remote superuser (root) when using identity authentication (local user is the same as remote user). It is primarily the feature of NFS but potentially may be available on other systems as well.
This problem arises when some remote file system is shared by multiple users. These users belong to one or multiple groups. In Unix, every file and folder normally has the separate permissions (read, write, execute) for the owner (normally the creator of the file), for the group to that the owner belongs and for the "world" (all other users). This allows to restrict write and read access only to the authorized users while in general NFS server must also be protected by firewall.
Superuser has more rights than the ordinary user, being able to change the file ownership, set arbitrary permissions and access all protected content. Even users that do need to have root access to they individual workstations may not be authorized for the similar actions on a shared file system. Root squash reduces rights of the remote root, making one no longer superuser. On UNIX like systems, root squash option can be turned on and off in /etc/exports file on a server side.
After implementing the root squash, the authorized superuser performs restricted actions after logging in into NFS server directly and not just by mounting the exported NFS folder.
SELinux
SELinux is the set of kernel extensions to control access more presicely, strictly defining both if and how files, folders, network ports and other resources can be accessed by the confined process. This system is mostly used to restrict processes (database, server) rather than human users. It can also limit processes that run as root. Other distributions use comparable alternatives like AppArmor.
Viruses and Virus Scanners
Unix-like operating systems are immune to most Microsoft Windows viruses because binaries created to run on Windows generally won't run on other platforms. However, many Unix like installations provide file storage services to Microsoft Windows clients, such as through the use of Samba software, and may unintentionally become a repository for viruses stored by users. It is common for Unix servers to act as Mail Transfer Agents consequently email virus scanning is often installed. The ClamAV virus scanner is available in source code form and may be used to scan Unix file systems for viruses which infect other operating systems.
There are viruses and worms that target Unix-like operating systems. In fact, the first computer worm -- the Morris worm -- targeted Unix systems.
Firewalls
Network firewall protects systems and networks from network threats which exist on the opposite side of the firewall. Firewalls can block access to strictly internal services, unwanted users and in some cases filter network traffic by content.
iptables
iptables is the current user interface for interacting with Linux kernel netfilter functionality. It replaced ipchains. Other Unix like operating systems may provide their own native functionality and other open source firewall products exist. More detailed information about iptables is contained elsewhere. A brief discussion is contained here in order to describe how iptables may be used to configure a Linux firewall.
netfilter provides a state-full packet filter which can be configured according to network interface, protocol, source and/or destination address, source and/or destination port and the state of the packet. A network packet traverses several chains between the time it is received by a network interface and the time it is accepted by the host or forwarded to another host. The common chains are INPUT, OUTPUT and FORWARD. The INPUT chain is traversed for all packets as they are received by a network interface, regardless of whether they are to be accepted by the host or forwarded to another host. The OUTPUT chain is traversed for all packets as they are transmitted by a network interface. The FORWARD chain is traversed for those packets are being routed through the host from one network interface to another, such as is the case for a multi-homed system (a system with more than one physical network interface).
Each of the built-in chains has a default policy which defines what action is taken for a packet which reaches the end of the chain. Packet traversal ends when a rule matches the packet and has an action of ACCEPT, DROP, REJECT or RETURN.
The simplest iptables firewall consists of rules for each desired service, followed by a rule which indicates that any packets which reach this rule are dropped. A system which only permitted, for example, incoming email traffic would have a rule which accepted connections on the SMTP port, and then dropped others. A rule would be required which indicated that all established connections were also permitted so that outgoing connections would receive responses from other systems.
INPUT chain
The following example shows a simple packet filter for the INPUT chain for the above described example:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere state ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
0 0 LOG all -- any any anywhere anywhere LOG level warning
0 0 DROP all -- any any anywhere anywhere
The addition of an explicit DROP action ensures that the packets are discarded should the default policy of the INPUT chain accidentally be changed to ACCEPT.
OUTPUT chain
There is less need for an OUTPUT chain and the default policy of the OUTPUT chain can safely be set to ACCEPT. In some instances it may be desirable for a firewall to limit certain outgoing connections to a certain set of approved systems. This is known as egress filtering and may be used to prevent viruses within the firewall from escaping to other systems. For example, it may be the policy of a network to limit outgoing email connections to a single authorized email servers as a way of combating e-mail spam. This could be achieved by the following example:
Chain OUTPUT (policy ACCEPT)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- any any !server anywhere tcp dpt:smtp
There is no need to include any other rules in this example as the default policy for the OUTPUT chain is ACCEPT. Note also that this rule assumes that the host which is acting as the firewall will not be sending email itself, such as to the email server. This is a good assumption as typically a firewall system contains the minimal amount of system code needed to act as a firewall.
A more restrictive OUTPUT chain would contain permissive (ACCEPT) entries for those services which may be accessed outside the firewall and then a restrictive (DROP) policy for the chain itself.
Posted by at

Filesystem permissions

Most current file systems have methods of administering permissions or access rights to specific users and groups of users. These systems control the ability of the users affected to view or make changes to the contents of the filesystem.
Differences between operating systems
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and all Mac OS X versions, have a simple system for managing individual file permissions, which in this article are called "traditional Unix permissions". Most of these systems also support some kind of access control lists, either proprietary (old HP-UX ACLs, for example), or POSIX.1e ACLs, based on an early POSIX draft that was abandoned, or NFSv4 ACLs, which are part of the NFSv4 standard.
DOS variants (including MS-DOS, Windows 95, Windows 98, and Windows Me) do not have permissions, only file attributes. There is a read-only attribute (R), which can be set or unset on a file by any user or program, and therefore does not prevent him/her from changing/deleting the file. There is no permission in these systems which would keep a user from reading a file.
OpenVMS (a.k.a. VMS), as well as Microsoft Windows NT and its derivatives (including Windows 2000 and Windows XP), use access control lists (ACLs)[1] to administer a more complex and varied set of permissions. OpenVMS also uses a permission scheme similar to that of Unix, but more complex. There are four categories(System, Owner, Group, and World) and four types of access permissions (Read, Write, Execute, and Delete). The categories are not mutually disjoint: World includes Group which in turn includes Owner. The System category independently includes system users (similar to superusers in Unix).[2]
Classic Mac OSes are similar to DOS variants and DOS-based Windows: they do not support permissions, but only a "Protected" file attribute.
The AmigaOS Filesystem, AmigaDOS supports a relatively advanced permissions system, for a single-user OS. In AmigaOS 1.x, files had Archive, Read, Write, Execute and Delete (collectively known as ARWED) permissions/flags. In AmigaOS 2.x and higher, additional Hold, Script, and Pure permissions/flags were added.
Mac OS X versions 10.3 ("Panther") and prior use POSIX-compliant permissions. Mac OS X, beginning with version 10.4 ("Tiger"), also support the use of NFSv4 ACLs. They still support "traditional Unix permissions" as used in previous versions of Mac OS X, and the Apple Mac OS X Server version 10.4+ File Services Administration Manual recommends using only traditional Unix permissions if possible. It also still supports the Mac OS Classic's "Protected" attribute.
Solaris ACL support depends on the filesystem being used; older UFS filesystem supports POSIX.1e ACLs, while ZFS supports only NFSv4 ACLs.[3]
Linux supports POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3 filesystem.[4]
FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.[5]
IBM z/OS implements file security via RACF (Resource Access Control Facility)[6]
Traditional Unix permissions
Permissions on Unix-like systems are managed in three distinct classes. These classes are known as user, group, and others. In effect, Unix permissions are a simplified form of access control lists (ACLs).
When a new file is created on a Unix-like system, its permissions are determined from the umask of the process that created it.
Classes
Files and directories are owned by a user. The owner determines the file's owner class. Distinct permissions apply to the owner.
Files and directories are assigned a group, which define the file's group class. Distinct permissions apply to members of the file's group members. The owner doesn't need to be a member of the file's group.
Users who are not the owner, nor a member of the group, comprise a file's others class. Distinct permissions apply to others.
The effective permissions are determined based on the user's class. For example, the user who is the owner of the file will have the permissions given to the owner class regardless of the permissions assigned to the group class or others class.
Permissions
There are three specific permissions on Unix-like systems that apply to each class:
• The read permission, which grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory (but not to find out any further information about them such as contents, file type, size, ownership, permissions, etc.)
• The write permission, which grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files.
• The execute permission, which grants the ability to execute a file. This permission must be set for executable binaries (for example, a compiled C++ program) or shell scripts (for example, a Perl program) in order to allow the operating system to run them. When set for a directory, this permission grants the ability to traverse its tree in order to access files or subdirectories, but not see the content of files inside the directory (unless read is set).
The effect of setting the permissions on a directory (rather than a file) is "one of the most frequently misunderstood file permission issues"[7].
When a permission is not set, the rights it would grant are denied. Unlike ACL-based systems, permissions on a Unix-like system are not inherited. Files created within a directory will not necessarily have the same permissions as that directory. The permissions to be assigned are determined using umasks.

Notation of traditional Unix permissions
Symbolic notation
There are many ways by which Unix permission schemes are represented. The most common form is symbolic notation.
Three groups of three
first what the owner can do
second what the group members can do
third what other users can do
The triplet
first r: readable.
second w: writable.
third x: executable.
s or t: executable and setuid/setgid/sticky.
S or T: setuid/setgid or sticky, but not executable.
The first character indicates the file type:
• - denotes a regular file
• d denotes a directory
• b denotes a block special file
• c denotes a character special file
• l denotes a symbolic link
• p denotes a named pipe
• s denotes a domain socket
Each class of permissions is represented by three characters. The first set of characters represents the user class. The second set represents the group class. The third and final set of three characters represents the others class.
Each of the three characters represent the read, write, and execute permissions respectively:
• r if the read bit is set, - if it is not.
• w if the write bit is set, - if it is not.
• x if the execute bit is set, - if it is not.
The following are some examples of symbolic notation:
• -rwxr-xr-x for a regular file whose user class has full permissions and whose group and others classes have only the read and execute permissions.
• crw-rw-r-- for a character special file whose user and group classes have the read and write permissions and whose others class has only the read permission.
• dr-x------ for a directory whose user class has read and execute permissions and whose group and others classes have no permissions.

Octal notation
Another common method for representing Unix permissions is octal notation. Octal notation consists of a three- or four-digit base-8 value.
With three-digit octal notation, each numeral represents a different component of the permission set: user class, group class, and "others" class respectively.
Each of these digits is the sum of its component bits (see also Binary numeral system). As a result, specific bits add to the sum as it is represented by a numeral:
• The read bit adds 4 to its total (in binary 100),
• The write bit adds 2 to its total (in binary 010), and
• The execute bit adds 1 to its total (in binary 001).
These values never produce ambiguous combinations; each sum represents a specific set of permissions.
These are the examples from the Symbolic notation section given in octal notation:
• "-rwxr-xr-x" would be represented as 755 in three-digit octal.
• "-rw-rw-r--" would be represented as 664 in three-digit octal.
• "-r-x------" would be represented as 500 in three-digit octal.
Here is a summary of the meanings for individual octal digit values:
0 --- no permission
1 --x execute
2 -w- write
3 -wx write and execute
4 r-- read
5 r-x read and execute
6 rw- read and write
7 rwx read, write and execute
Note the similarity to binary counting (starting at the right and going left):
0: 000
1: 001
2: 010
3: 011
4: 100
5: 101
6: 110
7: 111
Octal digit values can be added together to make Symbolic Notations:
(4=r)+(1=x) == (5=r-x)
(4=r)+(2=w) == (6=rw-)
(4=r)+(2=w)+(1=x) == (7=rwx)
Here is a summary showing which octal digits affect permissions for user, group, and other:
• UGO = User, Group, Other
• 777 = "-rwxrwxrwx" = rwx for all
• 754 = "-rwxr-xr--" = rwx for owner, r-x for group, r-- for other
• 124 = "--x-w-r--" = x for owner, w for group, r for other

Listing Permissions
ls -l prints symbolic notation for files and directories.
stat -c '%n %a %A' can be used to print out octal notation.
User private group
Some systems diverge from the traditional POSIX-model of users and groups, by creating a new group – a "user private group" – for each user. The "user private group" scheme can be preferred for a variety of reasons[8][9][10] including using a umask of 002 and not having every "user" able to write to newly created files. In this case however, no other users must be added to the "user private group" or they will have write-permission on all files.
Posted by at
Subscribe to: Posts (Atom)