Re: [RFC] vfs: cleanup of permission()



On Wed, Mar 01, 2006 at 12:45:44AM -0800, Trond Myklebust wrote:
On Tue, 2006-02-28 at 06:26 +0100, Herbert Poetzl wrote:
Hi Andrew! Christoph! Al!

after thinking some time about the oracle words
(sent in reply to previous BME submissions) we
(Sam and I) came to the conclusion that it would
be a good idea to remove the nameidata introduced
in September 2003 from the inode permission()
checks, so that vfs_permission() can take care
of them ...

Why? There may be perfectly legitimate reasons for the filesystem to
request information about the path. I can think of server failover
situations in NFSv4 where the client may need to look up the
filehandle for the file on the new server before it can service the
ACCESS call.

the second part is actually a hack to help nfs and fuse
to get the 'required' information until there is a proper
interface (at the vfs not inode level) to pass relevant
information (probably dentry/vfsmount/flags)

this is in two parts, the first one does the
removal and the second one fixes up nfs and fuse
by passing the relevant nd_flags via the mask

Note: this is just a suggestion, so please let
us know what you think

Firstly, the fact that the lookup intent flags happen not to collide
with MAY_* is a complete fluke, not a design. The numerical values of
either set of flags could change tomorrow for all you know.

Secondly, an intent is _not_ a permissions mask by any stretch of the
imagination.

see above

IOW: at the very least make that intent flag a separate parameter.

IMHO it would be good to remove them completely form the
current permission() checks.

best,
Herbert

Cheers,
Trond

-
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/
-
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/



Relevant Pages

  • Re: Executable shell scripts
    ... kernel sees the execute bit, looks at the shebang line and then does: ... Since read permission is off, ... The faq you're refering to is 10-12 years old. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: [PATCH v2 1/2] syslog: distinguish between /proc/kmsg and syscalls
    ...  * syslog function, returning 0 if permission is granted, -ve if not. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [PATCH] add a trivial patch style checker
    ... entry yell and we'll get it updated, ... anyone without permission. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [RFC] correct flags to f_mode conversion in __dentry_open
    ... We've always mapped 3 to "no permission" to read or write. ... It's a linuxism ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [git pull] drm
    ... and still don't have permission, you know as well as I do once lawyers are ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)