Comment 57 for bug 212098

Yes, after some tests, as Jessie said, this is currently fixed.

In a default ubuntu installation (tried with a fresh updated beta installation), all sudoers are part by default of sambashare group, even if samba package is not setup. I reckon this is because of smbclient default installation, but didn't give a deeper look at that.

So:
- non sudoer will not be part of this group, but as they wouldn't be let to initiate the share by installing samba, there is no problem.
- people who are sudoer (even created after installation time) are in the right group, so, they can initiate the share service and then use it without having to log in again.

I only see two cases when this kind of issue can happened:
* an admin privileges user create another admin user (let's say "admin2") with useradd/adduser command instead of GUI tools. Put him in the admin group (so, with sudoer privileges) but not in the sambashare one. If admin2 wants to initiate the sharing service, he will be able to install automagically samba, but he won't be able to use it without log in again (and so, without notification)
-> Do we want to handle that case? (this is a minor one for advanced user and people who use that may/should know that group addition can be taken into account only when relogin). I checked that the admin profile of the GUI tool is indeed combining the sambashare group for new created admin user and that's the case. A trick would be to test if the current sudoer who initiate the share service is in the sambashare group on its current environment.

* an user wants to share a folder on a machine. He haven't sudoer privileges and so, call an adminstrator, who will use the fast user switching applet (or the one in "System -> Log Out -> Switch user"). He initiates the share, see it works for him, add the user to the sambashare group by the user & group tool (in user properties: "User privileges -> Share files with the local network"). When unloging, revert back to the user session (unlocking it, so, with no session reload) and the addition to the group will not be taken into account. Maybe the administrator would have known that checking the GUI tool added the user to a group if he used the usermod command. But with this GUI tools, even advanced administrator may do not be aware that this action add a user to a group, and that a new login to take that changes effective will be needed.
-> Do we want to handle this case?