Bug 5066 - Group access implemented incorrectly for user's own group
Group access implemented incorrectly for user's own group
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
x86 Windows XP
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2007-11-09 14:17 UTC by rvjcallanan
Modified: 2007-11-09 14:17 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description rvjcallanan 2007-11-09 14:17:58 UTC
We have an "ownership-agnostic" Samba server/XP client implemetation whereby the domain admin has ownership of all files under a given share while individual user access is determined solely by group membership. To achieve this, we disabled client-side access control and we make use of Linux sticky directories and the Samba inherited ownership feature.

This setup is very reliable and admin-friendly, however there is a slight quirk in the case of user home and profile directories...

In this case, we assign user ownership to the domain admin as before but "group ownership" is assigned to the individual user. This should work fine as the host OS (Ubuntu 6.06 LTS) will verify if the user attempts to access his home or profile directory via a terminal.

However, Samba will deny access in this case, presumably because it figures that the user is not a member of his own group (as a cursory examination of /etc/groups might indicate).

A quick fix to this problem is to always add the user to his own group using the "usermod -G <username> -a <username>" command but this really should not be necessary.

Samba needs to faithfully replicate the access permissions of the host OS.