Re: open(..., O_CREAT|O_EXCL, 0400) on aufs over nfs4

[sfjro]

Hello Pip,

I am still considering how to support atomic_open(), but all of my
approach are not good. And I am start thinking that your approach is
better eventually.
Here is what I thought. If you have any comment, please let me know.


Support for a branch who has its -atomic_open()
--
The filesystems who implement its -atomic_open() are not majority, but
surely exist. For example NFSv4 does, and aufs should call NFSv4
-atomic_open, particularly for open(O_CREAT|O_EXCL, 0400). Other than
-atomic_open(), NFSv4 returns an error for this case. While I am not
sure whether all filesystems who have -atomic_open() behave like this,
but NFSv4 surely return an error.
Generally speaking, calling -atomic_open() is less important for other
open(2) cases.

In order to support -atomic_open() for aufs, there are a few
approaches.

A. Introduce aufs_atomic_open()
   - calls one of VFS:do_last(), lookup_open() or atomic_open() for
 branch fs.
B. Introduce aufs_atomic_open() calling create, open and chmod, an aufs
   user Pip Cet's approach
   - calls aufs_create(), VFS finish_open() and notify_change().
   - pass fake-mode to finish_open(), and then correct the mode by
 notify_change().
C. Extend aufs_open() to call branch fs's -atomic_open()
   - no aufs_atomic_open().
   - aufs_lookup() registers the TID to an internal object.
   - aufs_create() does nothing when the matching TID is registered, but
 registers the mode.
   - aufs_open() calls branch fs's -atomic_open() when the matching
 TID is registered.
D. Extend aufs_open() to re-try branch fs's -open() with superuser's
   credential
   - no aufs_atomic_open().
   - aufs_create() registers the TID to an internal object. this info
 represents this process created this file just now.
   - when aufs gets EACCES from branch fs's -open(), then confirm the
 registered TID and re-try open() with superuser's credential.

Pros and cons for each approach.

A.
   - straightforward but highly depends upon VFS internal.
   - the atomic behavaiour is kept.
   - some of parameters such as nameidata are hard to reproduce for
 branch fs.
   - large overhead.
B.
   - easy to implement.
   - the atomic behavaiour is lost.
C.
   - the atomic behavaiour is kept.
   - dirty and tricky.
   - VFS checks whether the file is created correctly after calling
 -create(), which means this approach doesn't work.
D.
   - easy to implement.
   - the atomic behavaiour is lost.
   - to open a file with superuser's credential and give it to a user
 process is a bad idea, since the file object keeps the credential
 in it. It may affect LSM or something. This approach doesn't work
 either.


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_15utm_medium=emailutm_campaign=VA_SF

Re: open(..., O_CREAT|O_EXCL, 0400) on aufs over nfs4

[sfjro]

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_15utm_medium=emailutm_campaign=VA_SF