On 2010-02-19, at 02:49, Aneesh Kumar K. V wrote:
On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@xxxxxxx>
wrote:
What is the expected lifespan of "fh" to remain valid in the kernel?
Presumably this is not just the encoding of the inode number into a
buffer, or it would be too easy to forge from userspace. That means
there needs to be some unguessable state in the kernel for each file
handle, that may potentially need to be kept indefinitely if there is
no expiry.
Will "fh" be portable between processes? I assume that is the
intent,
but good to declare the actual semantics of the syscalls before they
go into the kernel.
Life time rule and uniqueness rule should be same as the NFS file
handle. My understanding is there is no expiry.
Yes, and NFS file handles can be a pain in the ass, because it means
inode numbers/devices/fsid should never be changed for fear of
breaking NFS. I'd much rather advertise that handles have a limited
lifespan (e.g. at most until the server reboots, possibly sooner) so
that there isn't an expectation of them lasting forever.
I am not sure what would be the issues if one could guess the file
handle? It should be looked at as another way to identify a file.
The open call takes the mode and normal permissions checks are done
during open.
If you are worried about limiting file access by controlling the
permissions of directories i guess the below mail explained that we
cannot depend on directory permissions for such access restrictions http://article.gmane.org/gmane.linux.file-systems/37419
?
I don't think one person's opinion circumvents many years of POSIX
behaviour that the only way to access a file is to do path traversal
and have permission all the way down. It is one thing for a process
with access to the file to get a file handle and pass it to another
process (that can happen today already), but it definitely shouldn't
be possible for an arbitrary process to invent a file handle and get
access to a file to which it cannot do path traversal through any
existing path.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
