This isn't strictly a programming question, but I think the bright people in this forum will probably find the question interesting. If there is a better place, I'd be happy to have a mod move it.
</obligatory suck-up>

My question has to do with how and when group membership and filesystem permissions become effective. I will cite an example that I occasionally trip over to explain my query.

I am logged in, running applications in a desktop environment, including numerous shell sessions. In one of those shell sessions, I become root, and create a new group, and add myself as a member of that group. Then, I create some files and directories in the filesystem, give them group ownership by the group I just created, along with group-rwx permissions. So far, no problem. However, when I try to create or modify files in those directories that were just given the new group ownership, permission is denied. I then jump out of the desktop (Ctl-Alt-F2, to get a console), and find that the new login provides me all the access I expect in the filesystem areas just modified with the new group ownership & permissions.

Can someone explain what underlying mechanism or process is causing this behavior? Better still, how can I overcome it, without having to kill the current desktop session, and start a new one (to me, that's like the famous Windows reboot to load a program). Seemingly, there is something inherited at the original desktop login, and any process whose ancestry includes that login seems to have that trait. Any way to shake it off, or update the necessary characteristic?

I think if I understand what's at play, I can at least avoid letting it fool me in the future.

Thanks.

--- rod.

Filesystem permissions are immediate.

Group membership, UID, GID, home directory and default shell become effective for the next login or session. They are assigned only once, when the login or session is started.

In a shell session, you can run e.g.
to replace the current shell with a new login $SHELL, with the new settings.

For bash users, I recommend putting
into $HOME/.bashrc or even in /etc/bash.bashrc or /etc/bashrc (so it'll be defined for all users).
Note that the id command will only be run once, when the alias is assigned, to find out the user name even if $USER is not defined.

Hope this helps.

Groups aren't immediate. There is a command to update the auxiliary group list for a user, but I don't remember what it is. You may need to log out and log in again. Keep this in mind when changing visudo. You may even need to reboot then so that root's secondary group list is updated.

You can verify this by creating a new group, adding yourself as a member. And then entering the "groups" command. I tried it out myself, and the new group was added by logging out of KDE and logging in again. ( After switching to vt1, I had to do an init 3; init 5 to restart kdm for some reason.)

Thanks for the good answers.
Nominal Animal, I just have one question about your answer. What do you mean by the term 'session' in the phrase 'become effective for the next login or session'? I think I understand the concept of a login (feel free to expound on that as it relates to the question). What do you mean by the term 'session'?.
When I tried your command to get a new shell with the new settings, it simply closes the existing, uhh, 'session'. I tried it from a Konsole session on KDE 4.something (Debian 6.0) and from an Xterm. GNU bash, version 4.1.5. I think I understand what the command is trying to do, and I can't understand why it fails. Why would the following not work (it doesn't, I tried):
Thanks
--- rod.

After a little more online research, I have found that there exists a command 'newgrp', which is no doubt the one that jschiwal couldn't remember. It does the trick.
--- rod.

If you use a desktop environment like Gnome, KDE, or XFCE, it's called a 'session' rather than 'login'. Also, if you connect via SCP or SFTP, that is also usually called a session rather than a login. For SSH, I've seen both terms used. And sometimes you even see 'login session'.

That's because you need sudo rights to run that command. For example, line
where user is your username, in /etc/sudoers should suffice.

Note that if you only have changed the group memberships, you don't need to much around with sudo or /etc/sudoers at all, since
does the trick as you found. And yeah, I too forgot about newgrp!

Note that if you omit the exec, you'll just start a new subshell. With the exec, you replace the current shell with a new login shell.

(Running sudo -u "`id -un`" -i "$SHELL" actually changes to root first, then transitions back to the user, at which point all user settings are set. Unlike newgrp, this sudo incantation does apply all user settings, including user limits set by pam_limits.)

Because that just starts a new bash shell with your current identity; it does not do any kind of identity transition, and therefore does not look up any of the user identity settings (or user limits or anything related to logins or sessions).