On Tue, Feb 8, 2011 at 3:59 PM, Michael S. Zick <a...@morethan.org> wrote: > 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). > > Should not result in the entire directory contents, only the files that > where changed. And nothing except a rootkit should be writing to executables. >
Actually I just want to fake user ownership in the mount point so that userspace applications (like Wine) can write to it (which ends up in the rw branch). Currently the ownership and permissions come from the ro branch which the user doesn't have write permission to. Wine can't/won't write to the mount point even if the user has ownership of the rw branch. Since the ro branch is set ro and owned by a different account (or root) and the aufs mount point in the user's directory is mounted by root (fstab or pam_mount), there is no risk to the system by faking different ownership there. Any writes are going to be in the rw branch. It does work when looped through CIFS/SMB but that's an overcomplicated (and ugly due to the Gnome gvfs bug) solution. I'm not familiar with ACL capabilities on Linux. Does aufs support ACLs? The web page section seems to indicate no with "Features or just an idea in the future (see also design/*.txt)," http://aufs.sourceforge.net/ > 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. > Most Linux desktops have "switch-user" functionality so multiple users can be logged in but only one has keyboard/mouse access. A lot of older applications are supported well enough in Wine that additional dlls are not needed. Any with licensing that strict will have DRM with centrally registered key servers so concurrent usage license violations within a single site are unlikely. With internally developed applications the licensing is not an issue. Many businesses have such legacy applications that function on Wine and aren't worth rewriting. ------------------------------------------------------------------------------ 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
