In my shop, me a my colleagues use a RHEL jump server.
Each employee has its own login and home directories like
/home/johndoe
/home/katie
/home/steve
Each employee logs in to this server via their individual ID and it is authenticated via Microsoft Active Directory (I think).
So, once johndoe logs in, he can switch to appuser by runing su -iu appuser.
Now, appuser wants to copy a file to a directory called johns_Subdir located in johndoe's home directory.
johndoe has already granted chmod -R 777 johns_Subdir so that anyone can write to johns_Subdir.
But, appuser still cannot copy a file to /home/johndoe/johns_Subdir. It is probably because appuser does not have write privileges on johns_Subdir's parent directories /home/johndoe.
appuser@jumpserverp235:~ $ cp /home/appuser/appLog1.txt /home/johndoe/johns_Subdir
cp: failed to access ‘/home/johndoe/johns_Subdir’: Permission denied
appuser@jumpserverp235:~ $
appuser@jumpserverp235:~ $ ls -ld /home/johndoe
drwx------. 8 johndoe appadmin 280 Nov 30 16:26 /home/johndoe
appuser@jumpserverp235:~ $ cd /home/johndoe
bash: cd: /home/johndoe: Permission denied
appuser@jumpserverp235:~ $
But, johndoe does not want to give write privileges to anyone for /home/johndoe.
So, what is the solution for this ? I mean, how can johndoe let just appuser user to write files in /home/johndoe/johns_Subdir directory ?
Yes the x bit on a directory controls access ("axess").
An r bit in addition controls read/browse access - not needed here.
It's better to have a shared directory outside a private home directory.
Like /proj/group_dir
Or /home/group_dir
if group_dir never conflicts with a username.
The solutions provided will work and are a good fix, but keep in mind that anyone who knows the name of that directory (johns_Subdir) has been given read/write access and that could be dangerous. For example, say that the appuser generated a file containing salary information for everyone in the company and John wants that file copied to his own directory; since everyone else can read/write that directory, they could retrieve that information and even edit the report!
If you want to allow access to a single user other than John, you have two approaches. The first is to create a group that contains only johndoe and appuser, then give the directory ownership to that group, specifying permissions of rwxrwx--- (this prevents anyone else on the system from seeing the contents of the directory). This is flexible since other users could be added to the group in the future without changing the directory permissions, but creating/editing groups can only be done by the sys admin.
Another option is to use access control lists (ACLs). These allow permissions on individual files and directories to be specified for specific users and groups, so you could say that Bob and Alice have rwx, Chuck and Dan have rw-, and the Payroll group has r-x, for example. ACLs can be created by users without support from the sys admin. (Warning: ACLs can be difficult to backup and restore unless the sys admin is familiar with them and knows the proper procedures to use, so check with them if you think this is a good solution. The group solution in the previous paragraph doesn't require any special processing for such things.)
Of course, the final option is to sidestep the entire issue and instead of appuser copying into John's directory, have John copy the files from the original location. The same permission solutions listed above can be used, but turning the operation might make it easier to manage, since instead of it being John's, and Katie's, and Steve's responsibility to create their directories correctly, it's the appuser's responsibility to set up the original location permissions correctly (and it only needs to be done once).