in reply to Open a file of a different user

The solution depends on one of two scenarios: The individual home directories should not have world read write access, this is what group permissions and directories are for. Once you are given the username/password combination for another user, you also inherit the responsibilites for that data, and the other user inherits the responsibilities for your actions.

Run the idea of group (ie: shared) directories past your sysadm (and IT security staff). It will make things easier for all concerned.

Replies are listed 'Best First'.
Re^2: Open a file of a different user
by JavaFan (Canon) on May 12, 2010 at 01:57 UTC
    Most (all?) modern Unix systems allow for ACLs on files, which is much finer grained and less limiting than groups. When it's just two different users needed access to a single file, ACLs are the way to go. For instance:
    $ setfacl -m u:<other-user>:rw file
    will give <other-user> read/write access to the given file. Where <other-user> is either the user name or the user id. Note that on some OSses, you need to be root to set ACLs, and sometimes you may need an acl mount parameter.
      Javafan, please note that from a security standpoint:
      The individual home directories should not have world read write access, this is what group permissions and directories are for.
      If the user needs access to a file that is owned by another user, it should be stored in a common access area. In fact, there are some security related functions (of which SSH is one) that refuse to run if the user's home directory is world readable.
      File access controls are nice (and selinux context controls even nicer), but group read/write access (anything with more than one user) needs appropriate permissions set and enforced.
        If the user needs access to a file that is owned by another user, it should be stored in a common access area.
        Define "common access". Execute permission on the directory is enough, because all that's needed in finding the inode number given the file name:
        $ id -u 1500 $ id -g 1000 $ ls -ld Foo drwx--x--x 2 root root 4096 May 13 08:54 Foo $ cat Foo/bar Hello, world! $ sudo ls -l Foo total 4 -rw-r--r-- 1 root root 13 May 13 08:55 bar $
        In fact, there are some security related functions (of which SSH is one) that refuse to run if the user's home directory is world readable.
        Yes, and penguins are black and white. How does that relate to using file ACLs?