1PATH_RESOLUTION(2)         Linux Programmer's Manual        PATH_RESOLUTION(2)
2
3
4

NAME

6       Unix/Linux path resolution - find the file referred to by a filename
7

DESCRIPTION

9       Some  Unix/Linux  system calls have as parameter one or more filenames.
10       A filename (or pathname) is resolved as follows.
11
12
13   Step 1: Start of the resolution process
14       If the pathname starts with the  '/'  character,  the  starting  lookup
15       directory  is  the  root  directory  of the current process. (A process
16       inherits its root directory from its parent. Usually this will  be  the
17       root  directory  of  the  file hierarchy. A process may get a different
18       root directory by use of the chroot(2) system call. A process  may  get
19       an  entirely  private  namespace in case it — or one of its ancestors —
20       was started by an invocation of the clone(2) system call that  had  the
21       CLONE_NEWNS flag set.)  This handles the '/' part of the pathname.
22
23       If  the  pathname  does  not start with the '/' character, the starting
24       lookup directory of the  resolution  process  is  the  current  working
25       directory  of the process. (This is also inherited from the parent.  It
26       can be changed by use of the chdir(2) system call.)
27
28       Pathnames starting with a '/' character are called absolute  pathnames.
29       Pathnames not starting with a '/' are called relative pathnames.
30
31
32   Step 2: Walk along the path
33       Set  the  current  lookup  directory  to the starting lookup directory.
34       Now, for each non-final component of the pathname, where a component is
35       a substring delimited by '/' characters, this component is looked up in
36       the current lookup directory.
37
38       If the process does not have search permission on  the  current  lookup
39       directory, an EACCES error is returned ("Permission denied").
40
41       If  the  component  is not found, an ENOENT error is returned ("No such
42       file or directory").
43
44       If the component is found, but is neither a directory  nor  a  symbolic
45       link, an ENOTDIR error is returned ("Not a directory").
46
47       If the component is found and is a directory, we set the current lookup
48       directory to that directory, and go to the next component.
49
50       If the component is found and is a symbolic link  (symlink),  we  first
51       resolve this symbolic link (with the current lookup directory as start‐
52       ing lookup directory). Upon error, that  error  is  returned.   If  the
53       result  is not a directory, an ENOTDIR error is returned.  If the reso‐
54       lution of the symlink is successful and returns a directory, we set the
55       current  lookup  directory to that directory, and go to the next compo‐
56       nent.  Note that the resolution process here  involves  recursion.   In
57       order to protect the kernel against stack overflow, and also to protect
58       against denial of service, there are limits on  the  maximum  recursion
59       depth,  and  on the maximum number of symlinks followed. An ELOOP error
60       is returned when the maximum is exceeded ("Too many levels of  symbolic
61       links").
62
63
64   Step 3: Find the final entry
65       The  lookup  of the final component of the pathname goes just like that
66       of all other components, as described in the previous  step,  with  two
67       differences:  (i) the final component need not be a directory (at least
68       as far as the path resolution process is concerned — it may have to  be
69       a  directory,  or  a  non-directory, because of the requirements of the
70       specific system call), and (ii) it is not necessarily an error  if  the
71       component  is not found — maybe we are just creating it. The details on
72       the treatment of the final entry are described in the manual  pages  of
73       the specific system calls.
74
75
76   . and ..
77       By  convention,  every  directory  has  the entries "." and "..", which
78       refer to the directory itself and  to  its  parent  directory,  respec‐
79       tively.
80
81       The  path  resolution process will assume that these entries have their
82       conventional meanings, regardless of whether they are actually  present
83       in the physical filesystem.
84
85       One cannot walk down past the root: "/.." is the same as "/".
86
87
88   Mount points
89       After  a  "mount  dev  path" command, the pathname "path" refers to the
90       root of the filesystem hierarchy on the device "dev", and no longer  to
91       whatever it referred to earlier.
92
93       One  can walk out of a mounted filesystem: "path/.." refers to the par‐
94       ent directory of "path", outside of the filesystem hierarchy on "dev".
95
96
97   Trailing slashes
98       If a pathname ends in a '/', that forces resolution  of  the  preceding
99       component  as  in  Step  2: it has to exist and resolve to a directory.
100       Otherwise a trailing '/' is ignored.   (Or,  equivalently,  a  pathname
101       with a trailing '/' is equivalent to the pathname obtained by appending
102       '.' to it.)
103
104
105   Final symlink
106       If the last component of a pathname is a symbolic link, then it depends
107       on  the  system  call whether the file referred to will be the symbolic
108       link or the result of path resolution on its  contents.   For  example,
109       the  system  call  lstat(2)  will operate on the symlink, while stat(2)
110       operates on the file pointed to by the symlink.
111
112
113   Length limit
114       There is a maximum length for  pathnames.  If  the  pathname  (or  some
115       intermediate  pathname  obtained while resolving symbolic links) is too
116       long, an ENAMETOOLONG error is returned ("File name too long").
117
118
119   Empty pathname
120       In the original Unix, the empty pathname referred to the current direc‐
121       tory.   Nowadays  POSIX  decrees  that  an  empty  pathname must not be
122       resolved successfully. Linux returns ENOENT in this case.
123
124
125   Permissions
126       The permission bits of a file consist of three groups  of  three  bits,
127       cf.  chmod(1)  and  stat(2).  The first group of three is used when the
128       effective user ID of the current process equals the  owner  ID  of  the
129       file.  The  second group of three is used when the group ID of the file
130       either equals the effective group ID of the current process, or is  one
131       of  the  supplementary group IDs of the current process (as set by set‐
132       groups(2)).  When neither holds, the third group is used.
133
134       Of the three bits used, the first bit determines read  permission,  the
135       second  write  permission,  and  the last execute permission in case of
136       ordinary files, or search permission in case of directories.
137
138       Linux uses the fsuid instead of the effective  user  ID  in  permission
139       checks.  Ordinarily the fsuid will equal the effective user ID, but the
140       fsuid can be changed by the system call setfsuid(2).
141
142       (Here "fsuid" stands for something like "file  system  user  ID".   The
143       concept  was required for the implementation of a user space NFS server
144       at a time when processes could send a signal to a process with the same
145       effective user ID. It is obsolete now. Nobody should use setfsuid(2).)
146
147       Similarly, Linux uses the fsgid ("file system group ID") instead of the
148       effective group ID. See setfsgid(2).
149
150
151   Bypassing permission checks: superuser and capabilities
152       On a traditional Unix system, the superuser (root, user ID 0)  is  all-
153       powerful,  and  bypasses  all  permissions  restrictions when accessing
154       files.
155
156       On Linux, superuser privileges are divided into capabilities (see capa‐
157       bilities(7)).   Two  capabilities  are  relevant  for  file permissions
158       checks: CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH.  (A process has these
159       capabilities if its fsuid is 0.)
160
161       The  CAP_DAC_OVERRIDE capability overrides all permission checking, but
162       only grants execute permission when at least one of  the  file's  three
163       execute permission bits is set.
164
165       The CAP_DAC_READ_SEARCH capability grants read and search permission on
166       directories, and read permission on ordinary files.
167
168

SEE ALSO

170       capabilities(7)
171
172
173
174Linux 2.6.7                       2004-06-21                PATH_RESOLUTION(2)
Impressum