Using chmod I could set the permissions for a file, but if the parent ( .. ) directory had conflicting permissions, what would happen?

And if I create a new file, using touch or something similiar, how are the initial permissions calculated? Are permissions inherited it from ..?

And why can't I do anything in directory when I removed the executable permission flag?

$ mkdir temp;
$ chmod -x temp;
$ touch temp/a;
$ ls temp;
touch: cannot touch `temp/a': Permission denied
  1. There is -strictly speaking- no such thing in UNIX as "conflicting permissions": access permissions on an filesystem entry (directory, file, etc.) determine what you can or can not do on that object. Permissions on other filesystem entries do not enter into the picture, with the exception of the "x" bit on all ancestors directories in the path to a file (up to /) -- see 3.

  2. The default permission on a newly created file are determined by the permissions that the creating program allows (the mode argument to the open or creat system calls) and the current process umask. Specifically, any bit that is set (1) in the "umask" is reset (0) in the newly-created file permissions: in C-like notation: file_permissions = open_mode & ! umask. Read man 2 creat (look for O_CREAT) and man umask for the details.

  3. The "x" (executable) bit on a directory controls whether you can traverse that directory: traversing a directory means being able to cd into it and access files contained in it. Note that the ability to list the contents of the directory is controlled by the "r" bit.

Further reading:

  • So helpful. I'd +5(Informative) this if I could. – Kevin M Oct 6 '10 at 16:10
  • 1
    Slight nitpick to point 1: the kernel checks permissions on the path you pass to it, even if it's relative. So you can work in a directory that you couldn't chdir into via its full path (try it with mkdir foo/bar; cd foo/bar; chmod 000 ..; cd ..; ls -ld . ..; touch yes_I_can_write_here; chmod 755 ..; cd ..). This doesn't come up often (it's occasionally used in some process confinement scenarios). – Gilles 'SO- stop being evil' Oct 6 '10 at 18:52

First of all ... in Linux everything is a file. By everything I mean everything ... your folders, or mouse, or keyboard ... all is a file.

Now, let's answer your questions:

  1. There are no conflicts between folder and contained file. If you have a folder woth only read rights, but you have a file in that folder with write permissions, you can write to that file. However you can not create/delete files in that folder. So, don't worry about conflicts. Also you can read the contents of the folder (list the folder).

  2. Default permissions usually are 644 (meaning: rw for user, r for group and other)

  3. The "executable" bit for a directory means "listing" the directory. In other words, if you -x a folder, you can't know its content, that means you can't touch something into it.

  • 1
    If it's executable, then you can read something in it, or what's in a subdirectory, but you have to know the filename; you can't list the directory contents(read permission). To test this, create a directory with a file in it, remove all read permissions from the directory, cd out of the directory, and cat the file. – Kevin M Oct 6 '10 at 16:07
  • (2) Default file permissions are given by the umask (roughly speaking, it indicates bits that are excluded) and the permissions requested by the application that creates the file. The umask is often 022, resulting in permissions 755 if the program requests an executable file (argument 777), 644 if the application requests a public file (argument 666), and 600 if the application requests a private file (argument 600). (3) As Kevin says, you've mixed up execute and read permissions for a directory here. – Gilles 'SO- stop being evil' Oct 6 '10 at 18:58
  • OK, thanks for the extra info to my answer ... I just tried to explain it as simple as possible without excessive information. – Patkos Csaba Oct 7 '10 at 7:06
  • Re "in Linux everything is a file": Not entirely correct. There's no node in /dev for such devices as my Bluetooth radio or Ethernet card, for example. Higher-level concepts such as X11 windows don't appear as files either (exception: wmii). (BTW, the statement can be applied to Plan9 OS.) – grawity May 10 '11 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.