On Tue February 8 2011, Jeff Hanson wrote: > On Tue, Feb 8, 2011 at 2:44 AM, <sf...@users.sourceforge.net> wrote: > > Users have their own rw branch individually, don't they? > > chwon makes the file copied-up in aufs. So it never affect other users. > > > > Tried that. The result is that the rw branch ends up with the entire > data of the ro branch. It seems that aufs copies the entire file to > the rw branch even if only the ownership changes. Effectively: > aufs + chown = cp >
That is a property of "inode file systems" - only one location for ownership. Symbolic link chain at the directory name level - Hard links are many names-to-single inode - with one location for ownership. There are file systems (on non-*nix systems) that can "clone" the "data branch" independent of the "meta-data" - just not under *nix (I.E: Linux). The "work around" for that inherent property of inode file systems is the various systems of ACL meta-data. I.E: What you seem to want is a per-user Access Control List (ACL) that is created on-demand (rather than the data copied on-demand). > which eliminates my primary reason for using aufs which is to save > storage space by eliminating the need to replicate the entire contents > of the application directory in each users' home directory. > Should not result in the entire directory contents, only the files that where changed. And nothing except a rootkit should be writing to executables. Keep in mind that you don't want to disable the handling of "single use" restrictions for executables which are licensed that way. Many commercial programs that can be run with Wine on a multi-user machine are not (commonly) licensed for multiple concurrent use on a single machine. A common example is any Microsoft DLLs you let Wine access. They are almost always "single use per machine" licensed. Mike > > > > Then I am afraid the approach you wrote "faking uid internally" will be > > insecure either. > > > > No. From the user's perspective, only the file ownership within the > aufs mount point appears to change. The real ro branch remains owned > by root. They can modify the files as if they owned them but the > changes end up in the rw branch. The ro branch is not affected. > > > > > I'd suggest you to develop a fuse based one. > > > > I don't think that shell scripts can be used for that so I can't do > much until I learn C or find someone willing to write it for me. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
