Using a user space program for solving this problem is like using a user space unionfs. Another point: currently aufs can be used by docker to construct a container fs (as I can understand from a news). And ability to escape from conrainer is a security hole because application can open a file which root is outside of the container. This is the problem I speak about. aufs perform a inode translation. But don't have a file path translation layer. Kernel routine d_path return a real path for a file located inside union. Example: /mnt/union /branch_rw /branch_ro mount -t aufs o dirs=/branch_rw=rw,/branch_ro=ro none /mnt/union For the file README.txt in /branch_ro opened by program from /mnt/union/README.txt a path returned by a kernel d_path will be /branch_ro/README.txt and not a /mnt/union/README.txt Is a path translation layer implemented by current version of aufs?
PS: vfs magic for files inside union differ too 2014-07-17 7:02 GMT+04:00, sf...@users.sourceforge.net <sf...@users.sourceforge.net>: > > Sergey Korshunoff: >> I will try to explain the problem. A file from a union have a path >> which don't point inside a union. Insteed a file path is a real path >> to the file inside a branch. Checkpoint/restore can not deal with >> this. I solved a problen by using a user space bind utility (fuse >> bindfs). Using "mount -o bind UNIONS /vz/private/XXX" don't helped. > > Still I don't understand what you wrote. > Can I totally ignore your report since your problem is already solved? > Why don't you post the necessary information descirbed in aufs README > file? > > > J. R. Okajima > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
