Pip Cet:
> I've taken the code from fuse/dir.c and modified it slightly to provide a
> pretty minimal workaround, by creating the file with read/write permission
> first and then revoking that permission in a separate call to aufs_setattr
> if necessary. That's not perfect behavior (there is a window during which
> the extended preliminary permissions are visible), but it appears to work.
>From my understanding, such window is problematic.
As long as nfs4 has its ->atomic_open(), aufs should call it. The
sequence of
- open("file", O_CREAT|O_WRONLY, 0600);
- open("file", O_WRONLY);
- chmod("file", 0400);
is not atomic at all from nfs4's point of view.
My current idea is
- At the point where my previous patch prints, aufs creates a small
object of {pid, dentry} pair and holds internally.
- In aufs_create(), return 0 without processing if given {pid, dentry}
matches with the internally stored one. Otherwise, process normally.
- In aufs_open(), calls ->atomic_open if {pid, dentry} matches.
- The "exit notifier" may be necessary to free the internal pair, if the
task can abort in lookup after aufs creates the internal pair.
I don't think this idea is good, and still considering how to do it.
Anyway, your patch is surely one approach. Thanx.
J. R. Okajima
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
