OK, I have a very simple question.


Is it possible to share one folder between 2 users with full RW access without sharing every other directory they own outside that folder?


This seems straight forward enough to me. I've just asked it on #linux at irc.freenode.net but when we tried it became apparent that no one there could tell me how it was done.

Create a new group, called "sharing" or something, add those two users to it.

chmod g+s sets the set GID bit, so that anything created in that folder gets the group from the folder rather than the user's group

1 members found this post helpful.

They don't have access to create new files the folder unless I make sharing the user's primary group. And new folders/files don't inherit the 770 permissions.

The only way I've been told I can get around new files and folders getting permission 755 is to change umask in profile to 002 to create a default policy for (the users or everyone) of 775.

If I do this however the 2 users are able to access all files belonging to the other user.

I believe you will have to set up ACL -- if you are using redhat/centos.

http://www.linuxquestions.org/questi...ectory-791640/

This will help with that.

will help with further configuration. Honestly, I've never set up a box with the requirements that you are asking for -- i remember having to do it in a class, but that was a few years ago. Hope this helps.

szboardstretcher, thanks. Access Control Lists do look like they might do what I'm looking for. I'm on Arch Linux so a link for them is here. I am really surprised that this kind of thing isn't possible out of the box. I did think that Linux was more grown up than that. Oh, well.

The idea was to sandbox a untrustworthy app into a low grade user who only has access to a shared folder where files can be created, but allow my main user full access to those files.

There are secondary issues I've found with running an app as a user that needs access to X. Although sux may help.

Yes, well, the problem is not the operating system. The problem is that you are trying to do something that is generally a bad idea and any good operating system would make difficult.

It looks as if it should be possible, but you may need to tweak more than a little.
Luck!

No problem. Thanks for providing the Arch linux link.

Just a couple of thoughts on what I have been attempting. Firstly is that I was hoping to Sandbox an application by using a restricted user account, and that application was a X application. This appears to cause a not inconsiderable amount of issues with access to the array of files used by X applications and with session authorities. As one post I stumbled over pointed out if you don't trust an application then by the time it has access to X it has access to everything you do. I'm not sure how true this is. There don't seem to be many sandboxing solutions for linux at the moment and the ones that there are seem to be new. One of the more fully developed ones is SELinux.

You can run untrusted application in VM. In this case harm this application can do is very limited.

That doesn't match my experience. If you follow the steps szboardstretcher gave in his first reply, and you add both users to the "sharing" group, they can both create files in the folder group-owned by "sharing" regardless of whether "sharing" is the primary group of either user.

Keep in mind that, if you are actively logged in as userx, and you add userx to the "sharing" group, you must log out of userx completely and log back in before the new group assignment will take effect. Opening a new terminal will not work. Log out of the desktop completely.

Further, using the group-sticky on a directory will allow any group member to delete files within the group-owned directory, regardless of the listed group permissions on the file. I just verified this on an Ubuntu machine. I created two users, created primary groups for each based on their username, and manually added them to the "sharedfolder" group. I logged in with user1, touch'd file /home/shareit/user1_here.txt (owner:user1, group:sharedfolder, perms: 544), logged out, logged in with the user2, rm'd the touch'd file. I was asked if I wanted to delete the read-only file, said "yes", and the file was deleted.

That's not exactly true. Aside from what I mentioned above, you can set the umask on a per-user basis. Just change it in the specific user's ${HOME}/.bash_profile, ${HOME}/.bashrc, or whichever bash startup file meets your needs for your purpose.

I don't know if you said this because you thought that the "sharing" group had to be the primary group or not, but that certainly isn't the case. If user1's home directory is group-owned by user1, and user2's directory is group-owned by user2, then there should be no problem.

Maybe I'm missing something. If I am: my mistake.

As another option, you could also investigate running the untrusted application in a chroot'd/jail'd environment.

Dark_Helmet (snigger, awesome name) Thank you so much. The step I was missing was to completely log off and back on once I'd added myself to my group. That means Linux works how I would have expected it to after all! Thank goodness for that.

I couldn't understand how anyone would think it was a good idea to ignore the secondary groups when doing group permissions as it would lead to situations like I describe above where the only way to share new files would be to share every new file between 2 users as they would both have the same primary group.

Yep, that's exactly why I though everything had to be shared, it's an inescapable consequence of sharing the same primary group with umask of 002.

With regards to running a "sandboxed" application the Linux-y way seems to be to run the service as a daemon (if possible) and run that daemon as a low privilege user. In my case I was trying to run transmission, which as it happens has a daemonised version. It's a bit of a pain to set up, you need to edit the config by hand and dump your preferred bluetack style blocklist into the blocklists folder in your config directory and use gunzip to unzip it.

I also had to set up a user for use with the daemon, I made sure to give it a shell with no logins allowed - I choose /sbin/nologin

Anyway more detail on transmission daemon set up can be found here. One nice feature is that you can set the umask that transmission creates files using in the settings.json config file. The only thing is that it's in base 10 so my umask I wanted is fine 002 becomes 2 but if you wanted 022 then it would be written 18.