Reload changes from /etc/group

Latest response

If a user is logged in while changes in /etc/group than the changes are not applied to logged in user. How to reload the changes of /etc/group ??-

hr
Log in to join the conversation

Responses

Dusan Baljevic's picture Pro 469 points
16 July 2018 1:52 AM

Hi,

The change should be visible immediately.

Did you try this:

a) Check current group membership as a user. Let's call username "myuser":

groups

b) Add this user to some groups in /etc/group. For example:

echo "ZZZ:x:23123:myuser" >> /etc/group

As a good practice, always ensure that /etc/gshadow is in sync after modifying /etc/group:

grpck

c) Recheck user again (without logging out):

groups
newgrp ZZZ

It should work.

What problem did you actually have?

Regards,

Dusan Baljevic (amateur radio VK2COT)

hr Community Member 20 points
16 July 2018 3:18 AM

Thanks for response. But, I think this solution is not related to my problem. Let me describe it,

wheel group is by default sudo group add myuser to wheel group

ROOT>#  usermod -G wheel myuser

Log in to myuser and run

myuser>>$  sudo tail /var/log/messages

it run successfully During this process myuser is logged in another terminal

Now root removes myuser from wheel group

ROOT>#  groupmems -g wheel -d myuser

But myuser still can run sudo commands

myuser>>$  sudo tail /var/log/messages

My problem is how to sync or reload changes of /etc/group if user is logged on another terminal..

IG Active Contributor 142 points
16 July 2018 6:37 AM

Hi,

Maybe this will help.

Are you running NSCD? It can cache such information as Unix group memberships. Any other name services you use (LDAP, and so on)?

It could also be SUDO caching. It caches the right to elevate, but not the password. It does so for only five minutes, by default.

/etc/sudoers uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written containing the uid that was used to authenticate, the terminal session ID, and a time stamp (using a monotonic clock if one is available). The user may then use sudo without a password for a short period of time (5 minutes unless overridden by the timeout option). By default, sudoers uses a separate record for each tty, which means that a user's login sessions are authenticated separately. The tty_tickets option can be disabled to force the use of a single time stamp for all of a user's sessions.

Check timestamp_timeout in /etc/sudoers.

Regards,

Dusan Baljevic (amateur radio VK2COT)

hr Community Member 20 points
16 July 2018 8:56 AM

Yes that is ok that after one time sudo password is given it is not necessary to give password for some amount of time (as you said 5 minutes) But after a 5 minutes if a try it asks for sudo passwd and when I enter sudo password it is executing successfully. My doubt is user should not be able to perform sudo commands after removing from sudo group...

Dusan Baljevic's picture Pro 469 points
17 July 2018 3:30 AM

Hi,

Are you making changes in /etc/group or /etc/sudoers?

Changing /etc/sudoers file does not require a reboot or log off - changes are reflected immediately once the file is saved.

Visudo command is the recommended way to update sudoers content, since it protects against various failures.

Keeping changes in /etc/sudoers.d directory is a convenient way to add and remove permissions(application specific) instead of modifying the /etc/sudors file.

I could not replicate your problem on RHEL 7.4. It worked as expected. As soon as changes were done in /etc/sudoers, the permissions for user were updated, without user needed to log off and on.

Maybe you can provide more details of your scenario, including the O/S version?

Dusan Baljevic (amateur radio VK2COT)

hr Community Member 20 points
17 July 2018 3:59 AM

I am just changing /etc/group and changes are not reflected if user is logged in.. i just want to know is there any way to overcome this problem ??

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.