Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

User/group permission change not reflected immediately

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Post Reply
Message
Author
xuancong84
Posts: 1
Joined: 2021-09-02 03:23
Been thanked: 2 times

User/group permission change not reflected immediately

#1 Post by xuancong84 »

Dear Debian security team,

It seems that this issue (changes in user/group permission is not reflected immediately) is prevalent in many Linux/Distros such like Debian/Ubuntu/MX-Linux/etc., should we fix it sooner or later?

Steps to reproduce:
1. create a new group called secure01
addgroup secure01

2. create files that are only accessible by the group
mkdir /mnt/secure-folder
echo yes >/mnt/secure-folder/secure-file
chown -R root:secure01 /mnt/secure-folder/
chmod -R o-rwx /mnt/secure-folder

3. add an existing user into the group
usermod -a -G secure01 user01

BUG1:
if user01 is already logged in, he still cannot access /mnt/secure-folder/secure-file
ls: cannot open directory '/mnt/secure-folder/': Permission denied

4. del the user from the group
gpasswd -d user01 secure01

BUG2:
if user01 is already logged in or it has running tmux/screen sessions, he still can access that group's /mnt/secure-folder/secure-file
user01@local:~$ cat /mnt/secure-folder/secure-file
yes


This bug is significant for a multi-user secure Linux environment. In a secure network cluster, new data files are often dynamically added into the system with new group permissions created, and some users are added into the group or removed from the group depending on role change, task change, etc. However, the changed permission does not reflect immediately on all the running processes belonging to that user.

As a result, a user can have a persistent tmux/screen session (that does not go away unless reboot) to continue to access group files he can access once before, even though his access permission has been revoked now.

In order to fix this issue, I foresee 2 ways:
1. the access permission daemon must be notified whenever the file /etc/passwd or /etc/group changes, I think it is possible to make access permission daemon monitor file changes to these 2 files so that any changes to these 2 files will notify access permission daemon process to refresh latest changes.
2. create a new program to manually update the group-permission/group-id of all running processes, system admin just need to run this command after every user/group change 8)

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 times

Re: User/group permission change not reflected immediately

#2 Post by sunrat »

Bugs should be reported using reportbug - https://www.debian.org/Bugs/Reporting
I doubt Debian security team reads the forums.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

steve_v
df -h | grep > 20TiB
df -h | grep > 20TiB
Posts: 1400
Joined: 2012-10-06 05:31
Location: /dev/chair
Has thanked: 79 times
Been thanked: 175 times

Re: User/group permission change not reflected immediately

#3 Post by steve_v »

xuancong84 wrote: 2021-09-02 03:45is prevalent in many Linux/Distros
I think you mean "has been this way since day one in every GNU/Linux distribution, and this behaviour was inherited from UNIX"
Needing to log out/in to update group membership is not a bug, it's simply how the system was designed.

While this arrangement could indeed be improved, yet another daemon (or Dog forbid, systemd tentacle) is IMO not the answer.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

User avatar
donald
Debian Developer, Site Admin
Debian Developer, Site Admin
Posts: 1046
Joined: 2021-03-30 20:08
Has thanked: 186 times
Been thanked: 240 times

Re: User/group permission change not reflected immediately

#4 Post by donald »

From my environments, general practice for system process accounts that you have logged in via a change to /etc/passwd (from no login to bash then back for example), or for users is that you would just pkill/sighup/sigkill/hup their sessions to force a reset of that accounts permissions on the system and via a new session.

While yes this is a security issue in some specific areas it's part of the administration procedure that more than a few of us have gotten used to.

Highlighting it certainly brings attention to the issue and it may be noticed or picked up upstream ... but for an audit perspective logging a permission change and forced log out are pretty firm administrative trails.
Typo perfectionish.


"The advice given above is all good, and just because a new message has appeared it does not mean that a problem has arisen, just that a new gremlin hiding in the hardware has been exposed." - FreewheelinFrank

Post Reply