Re: [RFC] atomic create+open

[Trond Myklebust]

to den 06.10.2005 Klokka 16:38 (+0200) skreiv Miklos Szeredi:
> Currently it's impossible to implement a network filesystem that is
> 
>   a) served by an unprivileged userspace process
> 
>   b) supports "strange" open semantics, e.g.:
> 
>        open("foo", O_WRONLY | O_CREAT, 0400);
> 
>   c) not overly "hacky"
> 
> The basic problem is that because of a) permission checking cannot be
> separated from the actual operations.
> 
> By the time the ->open method is called, the file has been created
> with a read-only mode, and the server won't be able to open it in
> write mode.
> 
> Several hacks come to mind for solving this, but these have severe
> problems and are excluded.
> 
> One approach for solving this properly is to add a new atomic
> create+open method to inode operations.  The prototype would be a
> merger of ->create() and ->open, like this:
> 
>   int (*create_open) (struct inode *dir, struct dentry *dentry, int mode,
>                       struct file *filp);

The reason why we do it as a lookup intent is because this has to be
atomic lookup+create+open in order to be at all useful to NFS.

Just doing create+open atomically is worthless since it leaves you with
a bunch of races where someone on the server can create, say, a symlink
between the RPC call to lookup and the RPC call that creates the file.

> A different approach is to extend the open_intents structure and allow
> the filesystem to do the open from ->create(), but this is a much less
> clean interface. Trond Myklebust has a patch that does this (no longer
> applies):
> 
>   http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif

I'm going to fix this up.

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/