On Tue February 8 2011, Jeff Hanson wrote: > 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/ >
Sorry if what I wrote sounded like auFS supported stacked Access Control Lists (ACLs). I don't think it does, I don't think it should. The problems with trying to consolidate changes in multiple ACL controlled rw branches back into the single (master) ro branch seems mind-boggling (to me). For that use case, jro's suggestion of a custom, fuse based, file system layer that translates the current-user-specfic section of the master file's ACLs into current-user permissions may be what you need. As a WAFG, I suspect it would not be a trivial file system to write. ;-) You might also have to make some custom extensions to the ACL entries to help your fuse based system deal with things like: user-1 has mod-x, version-10 installed and user-3 has mod-x, version-15 installed. I.E: Manage per-user symbolic links for the file(s) related to "mod-x" based on the meta-data entries of the master's ACLs. As to ACL support in Linux - I think most of the "major" file systems have full ACL support (as a kernel compile time option - usually turned off). At this point I have to depend on my memory (a flaky thing to depend on) - I think that either (both?) VMS and Plan-9 file systems can do what you need for access control - but stackable under Linux - I think not. ;-) Mike > > 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
