Hello.

My first post here I would kindly ask for help on this:

I have a runnig bash script in the background (kind of a while loop). In the meantime a new user is added to the system. This user creates a directory/file and allows the user, who launched the script, to write to it.

However, the script cannot write to the directory/file telling me permission denied.

How can I refresh/reload/update the script's information about users and permission?

Many thanks for any ideas.

Martin

1. What is the user ID of the script, and what groups is that user in?

2. What permissions does the directory have, and what is the owner/group setting?

I think I set permissions correctly, because if I stop the script, logout/login and relaunch it, everything works smoothly. Could it be the script does not know, that there was a new group created, it belongs to... Anyway, here is the info:

script is called "listener":

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1002 6287 0.0 0.0 63816 708 ? S 14:48 0:00 /bin/bash ./listener

users and groups are as follows:
user "master" UID 1002 is a member of groups GID 1002, 1009
user "anewuser" UID 1009 is a member of group GID 1009

directory is set up like this: drwxr-x--- 1009 1009
the file existing in that directory is set up like this: -rw-rw---- 1009 1009

Please verify I understand this: the group with GID 1009 is created at the time the new user is created, and this is added as a supplemental group to master's account.

The new supplemental group is only available to new login shells. I'm not 100% of the reasons for this, or if there is some trick to add supplemental groups to already running processes. If there is, then that's probably a "proper" solution to your problem.

You can avoid the problem by taking a different approach with the groups. Instead of the directory in question having the GID 1009, create a shared group, lets call it "shared". Add this to the supplemental group of the master user, log out and in, and then start the process.

Then set the group setting for these directories to "shared", and the permissions such that member of this group can write to the directory, e.g.

newuser2's files will now have group "shared", and master should be able to write to them.

Thanks for your posts.

Yes, you understand my problem well. I would really need the "proper" solution, as you named it.

I fear the alternative solution you suggested is not applicable in my case, as there will be more "newusers" in the system and I cannot allow all of them to share the same group (shared), because I would like to keep each users data confidential.

There's the newgrp command, which re-loads group information, but it doesn't do it for the existing shell - it creates a sub-sell which the new group. Then it becomes a pain to find a way to execute commands in that sub-shell. If I was really pushed to do this, I would probably create an expect script to run newgrp, then inside that sub-shell, execute the commands I need to do, then exit from the sub-shell and then exit itself.

There might be a much better way to do it though.

Aha, I found a way using sudo, but it will depend on how/if sudo is set up on your system:

• create the new user
• add the new user's group to master's supplemental group list
• as master, run the copy commands with sudo, like this:
  
  Code:

  sudo -u master cp ...

  On Ubuntu, this does not prompt or a password, since the user is sudo-ing as himself, but I expect this is dependent on the config of sudo. Anyhow, the sudo'd commands will have the group. You can test it like this:
  
  Code:

  sudo -u master id

  You should see the supplemental group in the output of that command.