> > -----Original Message-----
> > From: Xuan Baldauf [mailto:xuan--reiserfs@baldauf.org]
> >
> > How is it done now? If some process chroots to /dir1/dir2, and tries to access
> > /dir1/dir2/file, does the access succeed or fail after a "chmod 000 /dir1"? Is the
> > current behaviour not incorrect, too?
> ---
> Under the current policy, the 'open', if the 'chrooted' user tried to
> access /dir1/dir2/file, they would get 'file not found', since for them,
> '/dir1' doesn't exist. They can successfully open the file with '/dir2/file'
> or if their CWD=dir2, './file' or 'file' will also work.
Of course "accessing /dir1/dir2/file" is meant from the global viewpoint, the
application should access "file" or "/file". (I do not see why access to "/dir2/file"
could succeed, because the process already chrooted to "/dir1/dir2" and therefore would
try to access "/dir1/dir2/dir2/file" from the global POV,)
> To me, since user 'x' doesn't know about /dir1, the current behavior
> seems consistent.
Okay. So root cannot depend on setting the rights of /dir1 to "000", but usually it
works.
>
>
> 2nd case: Suppose chroot isn't done, but the user's CWD=dir2, and you
> change access to /dir1 as above, then the user can open './file' and 'file',
> but not '/dir1/dir2/file'.
>
> Before you say that is correct or incorrect, consider this:
>
> The inode referenced by '/dir1/dir2/file' can also be referenced (hard link)
> by '/dir3/file'. The user's CWD is /dir3. Someone prohibits access to
> /dir1. You don't want the permissions on 'file' changed (unless you did a
> -R) or the /dir3/file reference would improperly fail.
>
> Currently, when opening 'file', open checks access on the inode corresponding
> to 'file'.
I know that hard links (implemented in the current way) also somewhat mess up the idea
of grouping files into a directory and assigning rights to this bunch of files. (As
there might be alternative reachabilities.) (I probably should consider a chroot a kind
of temporary hard link, giving an alternative, independent way to reach files and
directories.)
> To implement inheritability, you would have to reference the
> user's CWD each time to create an absolute path back to the root then
> walk that pathname.
Only if you do "instant resolving", trying to avoid information duplication. As I
explained in other mails, I do not believe that this is necessary.
>
> I believe that negative performance impact would outweigh any benefits
> in this case.
>
> Another issue to consider in deciding a subjective 'correctness':
>
> Consider under currrent policy, user CWD="/dir1/dir2/dir3".
> File to access is "/dir1/dir4/file".
> Someone prohibits access to 'dir2'. If user uses an absolute pathname they
> will be 'ok', but if they use a relative pathname, "../../dir4/file" the
> open will fail.
>
> Which resolution method provides the user with 'least' surprise? If
> dir1 is really under /dirA/dirB/dirC[...]/dirZ, which do you think will
> provide the best performance / feature set -- resolving from 'root' using
> user's CWD, or resolving from relative pathename?
Of course, I would resolve using the shortest way (relative pathname). But the surprise
to be not able to access /dir1/dir4/file while it is globally reachable is high. (But
this is the way the system currently works, isn't it?). If I understand correctly,
prohibiting access to "dir2" means creating an "access barrier". Usually, it should
barrier accesses coming from the root down to the requested fs object. But in this case,
it's meaning is somewhat inverted. A process with CWD="/dir1/dir2/dir3" may access
everything inside the barrier (using "." as its starting point), but nothing outside of
it. Is this the intended way it should work? The ACL system might solve this ...
"feature".
>
>
> -l
>
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
Xuân. :o)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/