give a user access to a directory in another user's home

[sollen]

I'm developing an application in which one user must run java software that I'm compiling as another user. I wanted to give user A permission to see the bin direcory of my workspace, which is in the home directory of user B. I was wondering how can this be done? I gave the bin direcotry full read/execute premissions, but since it's in my home directory user A can't navigate to it.

I know there are a few ways I could get around the problem but they arn't very elegant. I was wondering if there is a simple method for giving a user access to a specific directory without giving access to all the parent directories. I tried symbolic link but user A still can't access it, and a hard link to a directory isn't allowed in Linux. I don't feel like making a hard link to every single file in the bin directory, and I'm not sure that would work anyways, since every recompile overwrites them.

[GNU-Fan]

That's what groups are for.
Put both users in the group which you name after your application.

Then set the concerning directory as belonging to & readable by group.

[sollen]

wouldn't I still need to modify all of my directories to give read/write access to the group before user A can access it? I can do that of course, but I was wondering if there was a better solution, a why to make the parent directories readable inorder to allow a user to access the one directory I want avilible.

Yeah I know I don't need to do things the way I descirbed to make things work, it just seems like something Linux should be able to do; and if Linux can do it then I would like to know how to do it. That way I have it in my list of 'cool techniques' I can use in the future.

[GNU-Fan]

If I remember correctly, you don't.
Lets say situation is like this:

home/usera/getsome/afile,txt

You'd only have to set "getsome" accessable. Maybe readable.
If afile.txt is group-readable, one could directly access the file by absolute path.
cp /home/usera/getsome/afile.txt .

But you couldn't list the files in the interim directory "home/usera/". That would require read-permission on the dir.

[Irithori]

GNU-Fan´s solution with groups would work, of course.
The user would need at least execute permissions on the directories,
as *each* one in the hierarchy will be checked with a stat-systemcall.

Another way is to use "bind mounts".
Basically you mount one directory to another.
So user A can *only* see the directory in B´s home, that is meant for him.

However, I would consider both approaches bad design.
Not all that can be done should be done.

- A homedirectory is -by definition- under the control of the user.
If (s)he decides to set new permissions, delete files, move files, whatever
(s)he may do so. It is his/her home.
However, this might affect that java sfoftware, that is apparently meant for a group of people.
- what happens, if user B leaves the company / works in another department / gets fired / etc?
If the java app is still in there, it makes it harder to clean up the server from deprecated user accounts.

-> general apps do not belong in homedirectories

They do belong into /usr/local
Filesystem Hierarchy Standard
and given proper user/group permissions.

That means, you need a installation method to copy from user B´s directory to /usr/local/
A installation method can be a bash script, a Makefile, or more likely a ant script, as this is about java

[sollen]

GNU-Fan´s solution with groups would work, of course.
The user would need at least execute permissions on the directories,
as *each* one in the hierarchy will be checked with a stat-systemcall.

I may be a little confused, so I just wanted to confirm I'm reading that sentence right. Your saying that changing user A and B to share a group *would* require me to go back and modify my home directory to give executable permissions for the user correct?

However, I would consider both approaches bad design.
Not all that can be done should be done.

I agree, to an extent. In my case the official lab development machine is correctly designed such that user A owns all files he needs with correct permissions. I'm only trying to give user A access to my home directory on my personal machine. I'm using the RPM I developed for the app to install it onto my computer, then I only need to modify only one part of script and it (should) allow me to run it from eclipse. Basically I'm using the RPM to skip most of the configuration by hand and keeping my personal machine as close to the configuration of our official lab machine, but I don't want to change my workspace and other personal settings to do so. I figure it's forgivable since I'm doing it with my home directory on my personal machine and I will know when/if I modify my own home.
....okay it's still a bad practice. Still I wanted to do it more to figure out rather it was possible, not because I thought it was good practice .

I'm going to play with the bind mounts method to see if it works. If it turns out to be too hard for a (queasy) newbie then I'll give up and just configure my computer properly.

[sollen]

I tried the mount binding suggestion and it worked...sort of. There is still the problem that I am running eclipse as root (since I wanted the app to run as root). That means it is compiling every class file with root:root for the owner every time I make a change. Still that isn't related to my original question, its due to my bad practice regarding eclipse. What can I say I don't play well with Linux.

I'll go ahead and mark this question as solved, since you've confirmed that it is possible to do what I wanted. Thanks for the help.

[Irithori]

I may be a little confused, so I just wanted to confirm I'm reading that sentence right. Your saying that changing user A and B to share a group *would* require me to go back and modify my home directory to give executable permissions for the user correct?

*for the group

See here for a experiment:

root@ducttape:~# groupadd testgroup
root@ducttape:~# useradd -g testgroup user_a
root@ducttape:~# useradd -g testgroup user_b
root@ducttape:~# mkdir /tmp/testdir
root@ducttape:~# touch /tmp/testdir/testfile
root@ducttape:~# chown -R user_b:testgroup /tmp/testdir
root@ducttape:~# chmod 700 /tmp/testdir
root@ducttape:~# chmod 640 /tmp/testdir/testfile

root@ducttape:~# ls -la /tmp/testdir/
insgesamt 8
drwx------  2 user_b testgroup 4096 2010-03-08 21:12 .
drwxrwxrwt 15 root   root      4096 2010-03-08 21:12 ..
-rw-r-----  1 user_b testgroup    0 2010-03-08 21:12 testfile


user_a@ducttape:/$ ls -la /tmp/testdir/testfile
ls: cannot access /tmp/testdir/testfile: Permission denied

root@ducttape:~# chmod 710 /tmp/testdir

user_a@ducttape:/$ ls -la /tmp/testdir/testfile
-rw-r----- 1 user_b testgroup 0 Mar  8 21:12 /tmp/testdir/testfile

So, the very least permissions is
- execute bit for the group on all directories
- read bit for the group on the files

Hmm, not sure if I got the problem 100%, but I have built (and still do build) RPMs.
Maybe the relocate feature is helpfull here?