Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

chmod command

News Recommended Links Access Control Unix permissions model Symbolic form Absolute form Horror stories SUID/SGID Checkers
Groups administration Unix Access Control Lists (ACL) Managing user accounts in Perl groups command Admin Horror Stories Unix History Humor Etc

WARNING: chmod, especially recursive chmod is a very sharp weapon and should be used with appropriate caution. See Admin Horror Stories

For an introduction to classic Unix permissions  see Unix permissions model. Another good introduction to Unix permissions is available from IBM Developer works: Manage file permissions and ownership

When you create a file in Unix, its initial permissions depend on the current umask value (which is discussed later). You can change a file's permissions with the chmod  command or the chmod( )  system call. You can change a file's permissions only if you are the file's owner (or root). Unless this is NFS file or file on partition mounted with specific attributes (like nosuid, noexec, etc), root can change the permissions of any file .

The chmod  command allow two forms of specifying permissions: absolute and symbolic. Misunderstanding permission or applying them without much thought or testing (especially using  the exec option of find command) created a special genre of Unix horror stories which we might call "creative usage of permissions" ;-). See below Horror stories

Symbolic form

chmod command lets you specify which of a file's permissions you wish to change. This usage is called symbolic form:

chmod [-Rfh] [agou][+-=][rwxXstugol] filelist

This command changes the permissions of filelist, which can be either a single file or a group of files. The letters agou specify whose privileges are being modified. You may provide none, one, or more, as shown in the table

Letter

Meaning

a

Modifies privileges for all users

g

Modifies group privileges

o

Modifies others' privileges

u

Modifies the owner's privileges

The symbols specify what is supposed to be done with the privilege. You must type only one symbol:

Symbol

Meaning

+

Adds to the current privilege

-

Removes from the current privilege

=

Replaces the current privilege

The last letters specify which privilege will be modified:

Letter

Meaning

Options for all versions of Unix

r

Read access

w

Write access

x

Execute access

s

SUID or SGID

t

Sticky bit[

Options for BSD-derived versions of Unix only

X

Sets execute only if the file is a directory or already has some other execute bit set

u

Takes permissions from the user permissions

g

Takes permissions from the group permissions

o

Takes permissions from other permissions

Option for System V-derived versions of Unix only

l

Enables mandatory locking on file

The -R option causes the chmod command to run recursively. In this case if you specify a directory in filelist, that directory's permissions change, as do all of the files contained in that directory. If the directory contains any subdirectories, the process is repeated.

The -f option prevents chmod from reporting any errors encountered. This processing is sometimes useful in shell scripts if you don't know whether the filelist exists or if you don't want to generate an error message.

The symbolic form of the chmod command is useful if you only want to add or remove a specific privilege from a file. For example, if  we wanted to add group write permission to the file notes, we could use the command:

ls -l notes
-rw-r--r-- 1 joeuser    staff    4320 Feb  9 13:20 notes
chmod g+w notes
ls -l notes
-rw-rw-r-- 1 joeuser    staff    4320 Feb  9 13:20 notes

To remove read privilege for anybody who is not in group staff we can use   the command:

% chmod o-r notes
% ls -l notes
-rw-rw---- 1 joeuser    staff    4320 Feb  9 13:20 notes
%

To make file accessible only by owner we can remove all group and world (tohers) privileges:

% chmod go= invoice
% ls -l invoice
-rw------- 1  joeuser    staff   4320 Feb  9 13:20 invoice

Changing a file's permissions does not change its modification time (although it will alter the inode's ctime).

Absolute form

You can also use the chmod command to set a file's permissions, without regard to the settings that existed before the command was executed. This format is called the octal form of the chmod command:

chmod [options] mode filelist

in which the options have the following meanings:

After options you specify two parameters: mode and fileslist

To use this form of the chmod command, you must calculate the octal value of the file permissions that you want. The next section describes how to do this.

 Calculating octal file permissions

chmod allows you to specify a file's permissions with a four-digit octal number. You calculate the number by adding the permissions. Technically, we are OR-ing the values together.

Octal numbers and permissions

Octal number

Permission

4000

Set user ID on execution (SUID)

2000

Set group ID on execution (SGID)

1000

"Sticky bit"

0400

Read by owner

0200

Written by owner

0100

Executed by owner

0040

Read by group

0020

Written by group

0010

Executed by group

0004

Read by other

0002

Written by other

0001

Executed by other

Thus, a file with the permissions "-rwxr-x—-" has a mode of 0750, calculated as follows:

0400

Read by owner

0200

Written by owner

0100

Executed by owner

0040

Read by group

0010

Executed by group

0750

Result

 Common file permissions

Octal number

File

Permission

0755

/bin/ls

Anybody can copy or run the program; the file's owner can modify it.

0711

$HOME

Locks a user's home directory so that no other users on the system can display its contents, but allows other users to access files or subdirectories contained within the directory if they know the names of the files or directories.

0700

$HOME

Locks a user's home directory so that no other users on the system can access its contents, or the contents of any subdirectory.

0600

/usr/mail/$USER and other mailboxes

The user can read or write the contents of the mailbox, but no other users (except the superuser) may access it.

0644

Any file

The file's owner can read or modify the file; everybody else can only read it.

0664

groupfile

The file's owner or anybody in the group can modify the file; everybody else can only read it.

0666

writable

Anybody can read or modify the file.

0444

readable

Anybody can read the file; only the superuser can modify it without changing the permissions.

 

Common directory permissions

Octal number

Directory

Permission

0755

/

Anybody can view the contents of the directory, but only the owner or superuser can make changes.

1777

/tmp

Any user can create a file in the directory, but a user cannot delete another user's files.

0700

$HOME

A user can access the contents of his home directory, but nobody else can.

After you have calculated the octal file permission that you want, you can use the chmod command to set the permissions of files you own.

For example, to make all files in the directory executable by group and world you can use the command:

chmod 755 *

Horror stories: creative usage of permissions

Recursive permission change can be as disastrous as rm command


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News

[Dec 18, 2010] Learn Linux, 101 Manage file permissions and ownership

Octal permissions

So far you have used symbols (ugoa and rxw) to specify permissions. There are three possible permissions in each group. You can also set permissions using octal numbers instead of symbols. Permissions set in this way use up to four octal digits. We will look at the first digit when we discuss attributes. The second digit defines user permissions, the third group permissions and the fourth other permissions. Each of these three digits is constructed by adding the desired permissions settings: read (4), write (2), and execute (1). In the example for hello.sh in Listing 5, the script was created with permissions -rw-r--r--, corresponding to octal 644. Setting execute permission for everyone changed the mode to 755.

Using numeric permissions is very handy when you want to set all the permissions at once without giving the same permissions to each of the groups. Use Table 2 as a handy reference for octal permissions.

Table 2. Numeric permissions
Symbolic Octal
rwx 7
rw- 6
r-x 5
r-- 4
-wx 3
-w- 2
--x 1
--- 0

Access modes

When you log in, the new shell process runs with your user and group ids. These are the permissions that govern your access to any files on the system. This usually means that you cannot access files belonging to others and cannot access system files. In fact, we as users are totally dependent on other programs to perform operations on our behalf. Because the programs you start inherit your user id, they cannot access any filesystem objects for which you haven't been granted access.

An important example is the /etc/passwd file, which cannot be changed by normal users directly, because write permission is enabled only for root: However, normal users need to be able to modify /etc/passwd somehow, whenever they need to change their password. So, if the user is unable to modify this file, how can this be done?

suid and sgid

The Linux permissions model has two special access modes called suid (set user id) and sgid (set group id). When an executable program has the suid access modes set, it will run as if it had been started by the file's owner, rather than by the user who really started it. Similarly, with the sgid access modes set, the program will run as if the initiating user belonged to the file's group rather than to his own group. Either or both access modes may be set.

Listing 8 shows that the passwd executable is owned by root:

Listing 8. suid access mode on /usr/bin/passwd
[ian@echidna ~]$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 34368 Apr  6  2010 /usr/bin/passwd

Note that in place of an x in the user's permission triplet, there's an s. This indicates that, for this particular program, the suid and executable bits are set. So when passwd runs, it will execute as if the root user had launched it with full superuser access, rather than that of the user who ran it. Because passwd runs with root access, it can modify /etc/passwd.

The suid and sgid bits occupy the same space as the x bits for user and group in a long directory listing. If the file is executable, the suid or sgid bits, if set, will be displayed as lowercase s, otherwise they are displayed as uppercase S.

While suid and sgid are handy, and even necessary in many circumstances, improper use of these access mode can allow breaches of a system's security. You should have as few suid programs as possible. The passwd command is one of the few that must be suid.

Setting suid and sgid

The suid and sgid bits are set and reset symbolically using the letter s; for example, u+s sets the suid access mode, and g-s removes the sgid mode. In the octal format, suid has the value 4 in the first (high order) digit, while sgid has the value 2.

Directories and sgid

When a directory has the sgid mode enabled, any files or directories created in it will inherit the group id of the directory. This is particularly useful for directory trees that are used by a group of people working on the same project. Listing 9 shows how user greg could set up a directory that all users of the development group could use, along with an example of how user gretchen could create a file in the directory. As created, the file gretchen.txt allows groups members to write to the file, so gretchen uses chmod g-w to disable group write capability.


Listing 9. sgid access mode and directories
                    
[greg@echidna ~]$ mkdir lpi101
[greg@echidna ~]$ chmod g+ws lpi101
[greg@echidna ~]$ ls -ld lpi101
drwxrwsr-x. 2 greg development 4096 Nov 30 13:30 lpi101/
[greg@echidna ~]$ su - gretchen
Password: 
[gretchen@echidna ~]$ touch ~greg/lpi101/gretchen.txt
[gretchen@echidna ~]$ ls -l ~greg/lpi101/gretchen.txt
-rw-rw-r--. 1 gretchen development 0 Nov 30 14:12 /home/greg/lpi101/gretchen.txt
[gretchen@echidna ~]$ chmod g-w ~greg/lpi101/gretchen.txt
[gretchen@echidna ~]$ ls -l ~greg/lpi101/gretchen.txt
-rw-r--r--. 1 gretchen development 0 Nov 30 14:12 /home/greg/lpi101/gretchen.txt

Any member of the development group can now create files in user greg's lpi101 directory. As Listing 10 shows, other members of the group cannot update the file gretchen.txt. However, they do have write permission to the directory and can therefore delete the file.


Listing 10. sgid access mode and file ownership
                    
[gretchen@echidna ~]$ su - tom
Password: 
[tom@echidna ~]$ echo "something" >> ~greg/lpi101/gretchen.txt
-bash: /home/greg/lpi101/gretchen.txt: Permission denied
[tom@echidna ~]$ rm ~greg/lpi101/gretchen.txt
rm: remove write-protected regular empty file `/home/greg/lpi101/gretchen.txt'? y
[tom@echidna ~]$ ls -l ~greg/lpi101/
total 0

The sticky bit

You have just seen how anyone with write permission to a directory can delete files in it. This might be acceptable for a workgroup project, but is not desirable for globally shared file space such as the /tmp directory. Fortunately, there is a solution.

The remaining access mode bit is called the sticky bit. It is represented symbolically by t and numerically as a 1 in the high-order octal digit. It is displayed in a long directory listing in the place of the executable flag for other users (the last character), with the same meaning for upper and lower case as for suid and sgid. If set for a directory, it permits only the owning user or the superuser (root) to delete or unlink a file. Listing 11 shows how user greg could set the sticky bit on his lpi101 directory and also shows that this bit is set for /tmp.


Listing 11. Sticky directories
[greg@echidna ~]$ chmod +t lpi101
[greg@echidna ~]$ ls -ld lpi101 /tmp
drwxrwsr-t.  2 greg development  4096 Nov 30 14:16 lpi101
drwxrwxrwt. 24 root root        12288 Nov 30 14:22 /tmp

On a historical note, UNIX® systems used to use the sticky bit on files to hoard executable files in swap space and avoid reloading. Modern Linux kernels ignore the sticky bit if it is set for files.

Access mode summary

Table 3 summarizes the symbolic and octal representation for the three access modes discussed here.


Table 3. Access modes
Access mode Symbolic Octal
suid s with u 4000
sgid s with g 2000
sticky t 1000

Combining this with the earlier permission information, you can see that the full octal representation corresponding to greg's lpi101 permissions and access modes of drwxrwsr-t is 3775. While the ls command does not display the octal permissions, you can display them using the find command as shown in Listing 12

[comp.security.announce] CERT Advisory CA-96.25 - Sendmail Group Permissions Vulnerability

sendmail Group Permissions Vulnerability

WU-FTPD Development Mailing List Group permissions for real and anonymous users

Below you will find a bit of pseudocode describing my understanding of
users, classes, group permissions, etc. under wu-ftpd.

Interspersed in the code are four (4) questions. I'm pretty sure - in
fact I hope - that my understanding is incorrect, but I need your help
to figure out where.

At this point, imagine that a user ftp's into wu-ftpd system.

if user is anonymous
ftpd chroots to ~ftp

if anonymous user's domain matches a domain in a class command,
anonymous user is assigned a special class
[Q1: How can you tell if the class command works?]

if the anonymous user's class is in an autogroup command,
anonymous user is granted command's group privileges
[Q2: If this command works for anyone, could
you please explain how you did it and how you
can tell if it worked or not?]
else
anonymous user's access depends on other privileges
end ifend if

else if user is real
ftpd chroots to real user's home directory,
so real user cannot get to ~ftp directory!
[Q3: Is there any way to allow access to ~ftp?]

if real user is declared as groupguest in ftpaccess,
real user can access files under ~user
else
real user can access files under ~user
end if
[Q4: Even if the groupguest command worked
(and I can't get it to), real users still
can't access ~ftp, can they?]

end if

I would appreciate any help you can give me on these questions.

George

Take Command: The chmod Command by Eric Goebelbecker
January 01, 1996 | Linux Journal

Need to change who has access to your directories and files to protect your data? Eric explains the procedure using chmod.

Do you know how to rename a file you can't read? Better yet, do you know how other users can rename your files? Have you ever ftp'd a program from another host and been unable to run it?

The subject of file permissions, and how to manipulate them with the chmod command, is a good place to start learning about these situations.

First, let's create a file and examine its long listing. (In order to fit in the magazine, all the listings in this article are trimmed to fit.)

$ touch test_file
$ ls -l test_file
-rw-rw-r--   1 eric     users

Since I created this file, it makes sense that the third column shows my user name as the file's owner and that the fourth shows my group. (On some systems, the group name may be the same as the user name.) As you follow along in these examples, you will see your username in place of ``eric''.

The leftmost column of the directory listing shows the file's mode. Mode is the term used to refer to a file's permissions. ls displays the file's type and mode together as a grouping of ten one-character fields:

Type Owner Group World - rwx rw- r--

The type field has several valid values. For the sake of this tutorial, we are only concerned with two: empty (-) for a regular file, and d for directories.

The other three columns cover the three classes of access that are stored for each file in a Unix-like file system. Linux (and Unix) evaluates access in terms of user ownership, group ownership and world (or other).

For each of these classes, rights are evaluated in terms of three operations: reading (r), writing (w) and executing (x). The permissions above specify ``full'' access for the owner, reading and writing for group, and only reading for world (an unusual combination used for demonstration). Those permissions specify that

Changing permissions

If test_file were a very important document that we did not want anyone to be able to modify or delete, we would need to remove write access from group:

$ chmod g-w test_file
$ ls -l test_file
-rw-r--r--   1 eric     users

We see that the w for group is now replaced with a -, signifying that write permission is denied to members of the group users.

If test_file contained sensitive information that only members of the group users should be able to review:

$ chmod o-r test_file
$ ls -l test_file
-rw-r-----   1 eric     users

Now we see that the last triplet of the mode field, which specifies permissions for world, are all dashes. This means that other users who do not belong to the users group have no permissions to do anything with test_file whatsoever.

The command line usage for chmod mode looks like this:

chmod [options] new-mode filename

The new mode is specified in octal mode or symbolic mode. We'll cover symbolic mode first. In the first example we used g-w to remove write permission for group. As you might be able to guess, g stood for group, - for remove and w represented write permission.

$ chmod g+wx test_file
$ ls -l test_file
-rw-rwx---   1 eric     users

This operation added permission for group to write and execute.

Let's look at an example of these permissions in action.

$ chmod u-rwx test_file
$ ls -l test_file
----rwx---   1 eric     users
$ cat test_file
cat: test_file: Permission denied
$ cat .profile > test_file
bash: test_file: Permission denied

We are not able to display the file's contents because we do not have read access to our own file. When we specified u-rwx to chmod, we removed all access for the user (the file's owner). We were also denied permission when we attempted to add the contents of another file to it since we removed write access. (I should note that rm would still be able to delete this file, although it will normally request confirmation.)

$ chmod u+rwx test_file
$ ls -l test_file
-rwxrwx---   1 eric     users

When we specify u+rwx, all permissions are restored. Removing permissions from a file we own does not affect our ability to restore the permissions, because the mode is not stored in the file. It is stored in a structure called an inode entry. Only the owner of the file (and root) may modify this.

Understanding chmod

Let's look at a summary of chmod's options, and then cover each option in depth:

User

u user (owner)

g group

o other (world)

a all (user, group, and other)

Operation

+ add

- remove

= set exactly

Mode

r read

w write

x execute

X conditionally set execute

s Set UID or set GID

t set ``sticky'' bit

$ chmod a+rwx test_file
$ ls -l test_file
-rwxrwxrwx   1 eric     users 

This demonstrates the fourth possible symbol for user when using symbolic mode. We used a to set full permissions for all user classes at once. Let's delete the file and start over in order to demonstrate the difference between the = operator and the + and - operators. (From here on, we'll assume that you know how to get the directory listing, and won't list the ls command.)

$ rm test_file
$ touch test_file
-rw-rw-r--   1 eric     users
$ chmod g+x test_file
-rw-rwxr--   1 eric     users

This added execute permission for group.

$ chmod g=x test_file
-rw---xr--   1 eric     users

The = operators set group's permissions to execute, and in doing so removed read and write permission. While + and - set or unset the permissions specified, = will set exactly the mode specified and remove any others.

Read, write and execute modes are very straightforward when referring to files. Read and write allow a user to examine and modify/delete data from a file, respectively. Execute allows a user to execute a shell script or binary program. If you ftp a program from one host to another and then try to run it without setting execute permission, it will fail, since ftp does not set execute permission.

Directories

For directories, the rules can be a bit more complicated.

Read permission allows a user to examine the contents of a directory.

$ mkdir test_dir
$ touch test_dir/foo
$ ls test_dir
foo
$ chmod u-r test_dir
$ ls test_dir
ls: test_dir: Permission denied

Write permission allows a user to modify the contents of the directory. That means that lack of write permission on a directory does not prevent a user from modifying a file within the directory, if the file's permissions allow it. It does prevent the user from renaming, moving, deleting or creating any file in the directory. This is because a directory is a really a file that contains a list of filenames, and so read and write permission control access to that list.

$ chmod u=rx test_dir
dr-xrwxr-x   2 eric     users
$ touch test_dir/bar
touch: test_dir/bar: Permission denied
$ mv test_dir/foo ./foo
mv: cannot move `test_dir/foo' to `./foo':
Permission denied

This property also works the other way. Since write permission allows the modification of directory entries, a user can move or rename a file without permission to examine the contents. This is a very good reason for paying attention to write access for important directories.

To demonstrate:

$ ls -l test_dir
-rw-rw-r--   2 eric  users  foo
$ chmod u=rwx test_dir
$ chmod u=rx test_dir/foo
$ cat .bashrc > test_dir/foo
bash: test_dir/foo: Permission denied
$ mv test_dir/foo ./foo
$ ls test_dir
(It's empty)
$ ls foo
foo (It's in our present directory.)

Execute permission for directories (also referred to as search permission) is also very important. Execute permission is necessary for accessing a directory.

$ chmod u=rwx test_dir
$ cp ~/.bashrc test_dir
(any text file will do)
$ chmod u=rw test_dir
$ cd test_dir
bash: test_dir: Permission denied
$ cat test_dir/.bashrc
cat: test_dir/.bashrc: Permission denied

This copy of .bashrc does not do us a lot of good. However, setting execute permission for directory and not setting read or write can come in handy.

$ chmod u=x test_dir
$ cat test_dir/.bashrc
(we see the contents of the file)
$ ls test_dir
ls: test_dir: Permission denied

A directory that has execute permission only can be used to ``hide'' files. Only users who know the exact file name and path can access them; this includes both data files and programs.

Conditional execute

Let's return to test_file to examine the X option.

$ chmod u=rw,g=r,o=r test_file
-rw-r--r--   1 eric     users
$ chmod o+X test_file
-rw-r--r--   1 eric     users
$ chmod u+x test_file
-rwxr--r--   1 eric     users
$ chmod o+X test_file
-rwxr--r-x   1 eric     users 

In the first command, we see that we can set options for more than one class at a time by using a comma to separate the mode specifications. Here, we set the mode so that no user has execute permission. In the second command, we try to set execute permission for other with X. This fails, because X only works when one of the classes already has execute permissions. When we add execute permissions for owner, X sets executable permission for other.

The s option sets or removes set UID (SUID) and set GID (SGID) mode. These modes are very important in terms of UNIX/Linux security. When a file has SUID mode set, the process executing it has the effective rights of the file's owner for the duration of the program's execution.

For example, the program dip is used to create SLIP network connections. This requires root access, because creating a network interface device requires root access. Instead of forcing users to become root in order to use dip, which would require that the users know the root password, the dip program can belong to root and have the SUID mode set.

$ ls -l /usr/sbin/dip
-r-s--x---   1 root     dip

The s in the spot for user's execute field indicates the SUID mode is set. Another example of a use for the SUID mode is the passwd program, which allows users to modify the passwd (or shadow) file.

For security reasons, the SUID bit can affect only binary programs; it has no effect on shell scripts in Linux.

The SGID mode sets the group instead of the owner, and is set with (for example) g+s. It also has another purpose.

When a user creates a new file the group ownership defaults to the user's default group, which is the one listed in the passwd file. Sometimes users belong to more than one group and want to share files. The SGID mode can provide a convenient method for this. If the SGID mode bit is set for a directory, new files created in that directory will belong to that group, regardless of the creator's default group. If you belong to more than one group, try this. (You can check what groups you belong to with the id command. The default group is listed first, and you can use the chgrp command to change the group ownership of a file to another group you are a member of.)

$ mkdir test_dir
$ chgrp nondefault test_dir
$ chmod g+s test_dir
$ touch test_dir/foo
$ ls -l test_dir/foo
-rw-rw-r--   1 eric     nondefault

The SUID and SGID modes can be a security hole. However, when used carefully, they are very valuable tools and actually enhance system security by providing an alternative to distributing important passwords.

Make it simple

Specifying user classes can be used to simplify copying permissions.

$ chmod g=u test_file
-rwxrwxr-x   1 eric     users

This copied the permissions from user to group. All of the classes can be used on the right side of the +, - or = operators in this way.

$ chmod o-u test_file
-rwxrwx---   1 eric     users

This cleared all of the permissions that user has from other.

The last mode listed above is the t option, known as the ``sticky bit''. This mode is actually supported on the command line for compatibility purposes with shell scripts from older operating systems. It is not needed for Linux. If an installation guide instructs you to use it, it actually does nothing.

Do your math

File access modes can also be set using octal notation. This syntax is built by adding the mode fields together. For each user class, the fields are calculated this way:

Full permissions for any class would be 7, no permissions would be 0.

$ chmod 754 test_file
-rwxr-xr-x   1 eric     users

The classes are passed to chmod in the same order ls displays them. The mode we set is broken down this way:

      Owner = 4 + 2 + 1 = 7
      Group = 4 + 1     = 5
      World = 4         = 4

Octal mode is convenient because other utilities, such as find, expect modes to be expressed this way.

In octal mode, SUID and SGID are set by specifying them in another column before the user mode. For SUID use 4, for SGID use 2, and use 6 for both:

$ chmod 4755 test_file
-rwsr-xr-x   1 eric     users

Power chmod

Chmod also provides a few command line options to simplify administrative tasks. For changing file permissions in directory trees use -R.

$ chmod -R g-w test_dir

This would remove write permission for group for all of the files in and below test_dir.

In order to control the output of messages from chmod use -c, -v and -f:

$ chmod -v 700 test_file
mode of test_file changed to 0700 (rwx------)

This option caused chmod to display how the permissions of test_file were set. The -c option causes chmod to display messages only when files are changed, and the -f option suppresses messages about files that can't be changed.

Chmod also provides a --version option to display the version and --help to see a short help message.

Summary

File permissions are an integral part of Linux. The same concepts also apply to other operating system objects such as semaphores, shared memory, and NIS+. This tutorial provides you with some of the basic knowledge necessary to protect your data and have more fun with your Linux system, and provides you with mental building blocks for learning more about Linux.

Eric Goebelbecker is a systems analyst for Reuters America, Inc. He supports clients (mostly financial institutions) who use market data retrieval and manipulation APIs in trading rooms and back office operations. In his spare time (about 15 minutes a week...), he reads about philosophy and hacks around with Linux. He can be reached via email at [email protected].


Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Internal

External

Reference

chmod [OPTION]... MODE[,MODE]... FILE...
chmod [OPTION]... OCTAL-MODE FILE...
chmod [OPTION]... --reference=RFILE FILE...

This manual page documents the GNU version of chmod. chmod changes the permissions of each given file according to mode, which can be either a symbolic representation of changes to make, or an octal number representing the bit pattern for the new permissions.

The format of a symbolic mode is '[ugoa...][[+-=][rwxXstugo...]...][,...]'. Multiple symbolic operations can be given, separated by commas.

A combination of the letters 'ugoa' controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if 'a' were given, but bits that are set in the umask are not affected.

The operator '+' causes the permissions selected to be added to the existing permissions of each file; '-' causes them to be removed; and '=' causes them to be the only permissions that the file has.

The letters 'rwxXstugo' select the new permissions for the affected users: read (r), write (w), execute (or access for directories) (x), execute only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), sticky (t), the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file's group (g), and the permissions granted to users that are in neither of the two preceding categories (o).

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Any omitted digits are assumed to be leading zeros. The first digit selects the set user ID (4) and set group ID (2) and sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file's group, with the same values; and the fourth for other users not in the file's group, with the same values.

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals.

Sticky Files

On older Unix systems, the sticky bit caused executable files to be hoarded in swap space. This feature is not useful on modern VM systems, and the Linux kernel ignores the sticky bit on files. Other kernels may use the sticky bit on files for system-defined purposes. On some systems, only the superuser can set the sticky bit on files.

Sticky Directories

When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.

Options

Change the mode of each FILE to MODE.

-c, --changes
like verbose but report only when a change is made
--no-preserve-root
do not treat '/' specially (the default)
--preserve-root
fail to operate recursively on '/'
-f, --silent, --quiet
suppress most error messages
-v, --verbose
output a diagnostic for every file processed
--reference=RFILE
use RFILE's mode instead of MODE values
-R, --recursive
change files and directories recursively
--help
display this help and exit
--version
output version information and exit

Each MODE is of the form '[ugoa]*([-+=]([rwxXst]*|[ugo]))+'.

Author

Written by David MacKenzie and Jim Meyering.



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019