Re: [PATCH] VFS: document what MAY_ACCESS means

[Jamie Lokier]

Eric Paris wrote:
> The vfs MAY_ACCESS flag really means that we might not use the object
> immediately (consider chdir which might not actually use the new dir).
> Thus permissions must be checked rather than relying on checkes during
> later access of the object in question.  This patch just adds some
> documentation so the meaning of the flag is clear.  I would rename the flag,
> but it's already visable (although useless) to userspace.

As it's intended to clarify the meaning, I must admit that I didn't
find the comment clear at all!  I had to grep the code for MAY_ACCESS
to understand what your comment meant.

Especially what was meant by "chdir which might not actually use the
new dir".

Suggest: MAY_ACCESS means we are calling from access() or chdir() and
won't do the actual read/write/exec/appene/open, so ->permission()
must fully check the permission and not assume it can optimise away checks.

(Btw, side issue: I was very surprised to find fchdir() to an open
directory can fail on NFS due to change of permissions, so the pattern
dir = open("."); chdir("foo"); fchdir(dir) can fail to restore the
current directory).

-- Jamie


> 
> Signed-off-by: Eric Paris <eparis@xxxxxxxxxx>
> ---
> 
>  include/linux/fs.h |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 215b708..f683b29 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -51,6 +51,13 @@ struct inodes_stat_t {
>  #define MAY_WRITE 2
>  #define MAY_READ 4
>  #define MAY_APPEND 8
> +/*
> + * The vfs MAY_ACCESS flag really means that we might not use the object
> + * immediately (consider chdir which might not actually use the new dir).
> + * Thus permissions must be checked mmediately rather than relying on later
> + * checks during the actual user of the object in question.  This is an
> + * internal flag and should not come from userspace.
> + */
>  #define MAY_ACCESS 16
>  #define MAY_OPEN 32
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/