I have a problem with the latest Samba (3.0.25a) running under FreeBSD
(recent STABLE: FreeBSD 6.2-STABLE #41: Mon Jun 11 19:24:30 CEST 2007).
I run multiple Samba/FreeBSD file servers (in a Windows 2003 domain with
Windows 2003 DCs), and everything worked quite nicely until this week.
After an upgrade (both Samba and OS), I have a serious problem with
access.
I am using pam_winbind with windbind in my nsswitch.conf so that I can use
Windows users and groups, and winbind itself seems to be working properly
(I can enumerate, can see the the proper permissions on the servers under
BSD, etc.). But, for some reason that is not clear to me (perhaps I am
missing something obvious...), secondary groups seem to be ignored.
In a bit more detail:
I have a share that needs to be readable by all users (eg: all members of
DOMAIN#'domain users'), but writeable only by members of two
administrative
groups (eg: DOMAIN#'softwareadmin'). The problem is that even with the
share set to full control for 'softwareadmin' and read-execute for
'domain users', members of 'softwareadmin' cannot write to it
(and it
doesn't seem to make any difference if the permissions are extended ACLs
or not). The members of 'softwareadmin' are also members of 'domain
users',
and they can write to the share if I give 'domain users' full access --
but
that defeats the purpose, because then the share can be overwritten by
normal users.
And what is very strange is that in looking at the logs, everything appears
to be normal... I even get:
[2007/06/12 17:11:08, 10]
smbd/share_access.c:is_share_read_only_for_token(274)
is_share_read_only_for_user: share softwaretest is read-write for unix user
DOMAIN#user
right up until I try to write the file, at which point:
[2007/06/12 17:11:13, 10] smbd/open.c:fd_open(67)
fd_open: name New Bitmap Image.bmp, flags = 05002 mode = 0777, fd = -1.
Permission denied
[2007/06/12 17:11:13, 3] smbd/open.c:open_file(301)
Error opening file New Bitmap Image.bmp (NT_STATUS_ACCESS_DENIED)
(local_flags=2562) (flags=2562)
The maddening thing is that everything seems to be correct. The permissions
seem to be correct both from BSD and from Windows, and Samba even says that
the share is 'read-write' -- until I actually try to write something.
If anyone has ideas, I would love to hear them. I've done some searching on
various mailling lists and have been unable to find anything. I can provide
more information if needed.
--
greg byshenk - gbyshenk@byshenk.net - Leiden, NL
On Tue, Jun 12, 2007 at 06:25:13PM +0200, Greg Byshenk wrote:> I have a problem with the latest Samba (3.0.25a) running under FreeBSD > (recent STABLE: FreeBSD 6.2-STABLE #41: Mon Jun 11 19:24:30 CEST 2007). > > I run multiple Samba/FreeBSD file servers (in a Windows 2003 domain with > Windows 2003 DCs), and everything worked quite nicely until this week. > After an upgrade (both Samba and OS), I have a serious problem with > access.[...] As a followup: my apologies for the noise, as this was not a Samba problem. After reverting to Samba-3.0.24 (with the problem remaining present), further research indicated that the issue was related to the Domain, and not the Samba upgrade. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL
Timur I. Bakeyev
2007-Jun-13 13:31 UTC
[Samba] Samba 3.0.25a - FreeBSD - permissions problem?
Hi, Greg! On Tue, Jun 12, 2007 at 06:25:13PM +0200, Greg Byshenk wrote:> I have a problem with the latest Samba (3.0.25a) running under FreeBSD > (recent STABLE: FreeBSD 6.2-STABLE #41: Mon Jun 11 19:24:30 CEST 2007). > > If anyone has ideas, I would love to hear them. I've done some searching on > various mailling lists and have been unable to find anything. I can provide > more information if needed.It still possible that it's FreeBSD Samba3 port fault. There is a patch there, that addresses the problem with the incorrect handling of the supplimentary groups, where the bug results with behaviour like you described. Patch aimed to fix this problem, but lacks upper boundary check. It is in the file: patch-smbd_sec_ctx.c. You may try to remove this file and recompile the port. With regards, Timur Bakeyev.