Bug 6230 - 'force group' still broken in 3.3.2
'force group' still broken in 3.3.2
Status: RESOLVED INVALID
Product: Samba 3.3
Classification: Unclassified
Component: File services
3.3.4
Other Linux
: P3 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
http://bugs.debian.org/520309
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-29 04:04 UTC by Debian samba package maintainers (PUBLIC MAILING LIST)
Modified: 2009-08-30 06:01 UTC (History)
1 user (show)

See Also:


Attachments
Log of a failed attempt (12.69 KB, text/plain)
2009-03-29 04:05 UTC, Debian samba package maintainers (PUBLIC MAILING LIST)
no flags Details
Log of a successful attempt (16.08 KB, text/plain)
2009-03-29 04:06 UTC, Debian samba package maintainers (PUBLIC MAILING LIST)
no flags Details
Failed attempt (with force group), log level 10 (74.14 KB, application/octet-stream)
2009-03-29 18:01 UTC, Andras Korn
no flags Details
Successful attempt (without force group), log level 10 (110.36 KB, application/octet-stream)
2009-03-29 18:02 UTC, Andras Korn
no flags Details
Failed attempt with force group set to a domain group (74.53 KB, text/plain)
2009-03-29 18:12 UTC, Andras Korn
no flags Details
force group = +BUILTIN\Power Users (73.99 KB, text/plain)
2009-03-30 17:51 UTC, Andras Korn
no flags Details
force group = +Unix Users\guy (74.45 KB, text/plain)
2009-03-30 17:52 UTC, Andras Korn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian samba package maintainers (PUBLIC MAILING LIST) 2009-03-29 04:04:11 UTC
This is described in Debian bug #520309.

In Bugzilla 6155, we described some brokeness with 'force group', which was fixed in 3.3.2.

Apparently, another Debian user still found problems with 'force group'

From his words:

I have a samba pdc that uses an ldapsam backend. Everything seems to work,
with the expection of the following share:

[store]
        path = /store
        hide unreadable = yes
        csc policy = disable
        force group = +Power Users
        inherit acls = true
        volume = STORE
        create mask = 0666
        directory mask = 0777

When I connect to this share from either smbclient or Windows on a domain
workstation, the connection is denied and samba logs "make_connection:
connection to store denied due to security descriptor." If I comment out
"force group", connections succeed.

The users I tested with were members of "power users", but I also tested
with just "force group = username" (the name of the actual user), which
should have had no effect for that user as his primary gid was already his
own usergroup. But the connection was denied even so.

The [global] section of my smb.conf reads as follows:

[global]
        dos charset = CP852   
        display charset = UTF-8
        workgroup = KORN 
        netbios name = PDC
        server string = PDC
        auth methods = guest sam
        update encrypted = Yes
        obey pam restrictions = Yes
        passdb backend = ldapsam:ldap://192.168.0.99/
        pam password change = Yes
        passwd chat debug = Yes
        log level = 1
        debug class = yes
        debug prefix timestamp = yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        min protocol = LANMAN1
        announce version = 9.9
        name resolve order = lmhosts host wins bcast
        time server = Yes
        deadtime = 1440
        max smbd processes = 30
        socket options = SO_KEEPALIVE IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
        hostname lookups = Yes
        add machine script = /usr/local/sbin/add-machine "%u"
        logon script = %u.cmd
        logon path = 
        logon drive = N:  
        logon home = \\%L\%u\profile
        domain logons = Yes
        os level = 255
        preferred master = Yes  
        domain master = Yes
        ldap admin dn = cn=admin,dc=intra
        ldap group suffix = ou=Group
        ldap idmap suffix = ou=idmap
        ldap machine suffix = ou=Computers
        ldap passwd sync = Yes
        ldap user suffix = ou=People
        ldap suffix = dc=intra,dc=guy
        ldap ssl = no
        panic action = /usr/share/samba/panic-action %d
        ldapsam:trusted = yes
        ldapsam:editposix = yes
        admin users = root, Administrator
        hosts allow = 192.168.0.0/24, 127.0.0.0/8
        profile acls = Yes
        use sendfile = Yes
        hide dot files = No
        map archive = No   
        algorithmic rid base = 100000
        unix password sync = yes
        client ntlmv2 auth = yes
        acl group control = yes 
        force unknown acl user = yes
        smb ports = 445 139
        min receivefile size = 32k
        disable netbios = no
        reset on zero vc = yes
        ea support = yes
        map acl inherit = yes
        server signing = auto
        printcap name = cups 
        printing = cups
        cups options = "raw"
        mangle prefix = 3   
        hide special files = yes
        map read only = permissions
        wins support = yes
        preload = guy
        utmp = yes   
        delete readonly = yes
        dos filemode = yes
Comment 1 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-03-29 04:05:27 UTC
Created attachment 4034 [details]
Log of a failed attempt

This is a level 3 log of a failed attempt (with "force group" enabled, then)
Comment 2 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-03-29 04:06:16 UTC
Created attachment 4035 [details]
Log of a successful attempt

This is a log of a successful attempt (without "force group").
Comment 3 Volker Lendecke 2009-03-29 04:27:00 UTC
"denied due to security descriptor"

Very, very likely the smb.conf is not the whole story, but the user has put stuff into share_info.tdb. If the user does not intend to use security descriptors for shares, an option to test might be moving share_info.tdb away.

Can you test that?

If share_info.tdb intentionally contains security descriptors, please also upload that together with the output of "net getlocalsid" and "net getdomainsid".

Thanks,

Volker
Comment 4 Andras Korn 2009-03-29 07:42:36 UTC
(In reply to comment #3)

Hi,

> "denied due to security descriptor"
> 
> Very, very likely the smb.conf is not the whole story, but the user has put
> stuff into share_info.tdb. If the user does not intend to use security
> descriptors for shares, an option to test might be moving share_info.tdb away.
> 
> Can you test that?
> 
> If share_info.tdb intentionally contains security descriptors, please also
> upload that together with the output of "net getlocalsid" and "net
> getdomainsid".

Sorry, I didn't include this in my original report: I did come across the suggested "solution" of removing share_info.tdb and tried, but it didn't help. (It would also have surprised me if it had, as this is a completely new samba setup and to the best of my knowledge I didn't do anything fancy with share_info.tdb.)

Anyway, just to make sure, I tested again. I stopped smbd and nmbd, removed share_info.tdb, uncommented the force group line in smb.conf, started the daemons and tried to connect to the share via smbclient. Sure enough, I get "make_connection: connection to store denied due to security descriptor." in the log.

To be absolutely sure, I again commented the force group line out, restarted the daemons again, and tried smbclient again, and this time, it worked.
Comment 5 Volker Lendecke 2009-03-29 09:15:56 UTC
Just re-checked the code. The relevant piece is in make_connection_snum() where we print this debug message if share_access_check fails. And share_access_check only fails if a security descriptor in share_info.tdb denies access. If there is nothing in share_info.tdb, we fake up a security descriptor allowing everything to the World SID. The only thing I could imagine is that with "force group" being set we do not include the World SID in the user token.

Two things: To make 100% certain, can you do a

find / -name share_info.tdb

to make sure you removed the right share_info.tdb. Please don't feel offended by such a simple-looking request, I've seen quite a few of those.

Second, debug level 3 is not enough, we need a debug level 10 log of both the failure and success.

Thanks,

Volker
Comment 6 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-03-29 12:07:44 UTC
Just for the sake of it: 
share_info.tdb lives in /var/lib/samba with Debian packages
Comment 7 Andras Korn 2009-03-29 13:46:24 UTC
Hi,

> Two things: To make 100% certain, can you do a
> 
> find / -name share_info.tdb
> 
> to make sure you removed the right share_info.tdb. Please don't feel offended
> by such a simple-looking request, I've seen quite a few of those.

No offense taken; I can certainly do that (maybe later today or tomorrow), but it would be extremely surprising to find a share_info.tdb outside /var/lib/samba (which was the one I removed).

> Second, debug level 3 is not enough, we need a debug level 10 log of both the
> failure and success.

OK, will do. Stay tuned. :)

Thanks,

Andras
Comment 8 Andras Korn 2009-03-29 18:01:47 UTC
Created attachment 4036 [details]
Failed attempt (with force group), log level 10

Connecting with smbclient.
Comment 9 Andras Korn 2009-03-29 18:02:33 UTC
Created attachment 4037 [details]
Successful attempt (without force group), log level 10

Again, with smbclient.
Comment 10 Andras Korn 2009-03-29 18:08:18 UTC
(In reply to comment #7)

> > find / -name share_info.tdb
> > 
> > to make sure you removed the right share_info.tdb. Please don't feel offended
> > by such a simple-looking request, I've seen quite a few of those.
> 
> No offense taken; I can certainly do that (maybe later today or tomorrow), but
> it would be extremely surprising to find a share_info.tdb outside
> /var/lib/samba (which was the one I removed).

Sorry, no surprise (i.e. no other share_info.tdb).

> > Second, debug level 3 is not enough, we need a debug level 10 log of both the
> > failure and success.
> 
> OK, will do. Stay tuned. :)

Attached.

What immediately catches the eye is this:

Found group Power Users (S-1-5-32-547) not in our domain -- ignoring.lookup_name: Unix Group\Power Users => Unix Group (domain), Power Users (name)

And also this:

sid S-1-22-2-252 -> gid 252

I don't have this SID in my LDAP; group 252 is the power users group, and it looks like this:

dn: cn=Power Users,ou=Group,dc=intra,dc=guy
objectClass: posixGroup
objectClass: sambaGroupMapping
objectClass: top
cn: Power Users
userPassword:: e2NyeXB0fXg=
gidNumber: 252
memberUid: guy
sambaSID: S-1-5-32-547
sambaGroupType: 5
displayName: Power Users
Comment 11 Andras Korn 2009-03-29 18:12:34 UTC
Created attachment 4038 [details]
Failed attempt with force group set to a domain group

I set "force group = +guy" for this test to avoid the "not in our domain" message. Still can't connect.
Comment 12 Simo Sorce 2009-03-29 20:11:36 UTC
(In reply to comment #11)
> Created an attachment (id=4038) [details]
> Failed attempt with force group set to a domain group
> 
> I set "force group = +guy" for this test to avoid the "not in our domain"
> message. Still can't connect.
> 

Try using fully qualified names like:
Unix Users\guy
or
BUILTIN\Power Users
Comment 13 Andras Korn 2009-03-30 17:51:14 UTC
(In reply to comment #12)

> > I set "force group = +guy" for this test to avoid the "not in our domain"
> > message. Still can't connect.
> > 
> 
> Try using fully qualified names like:
> Unix Users\guy
> or
> BUILTIN\Power Users

Tried both, but still no luck (attaching logs). How/where/as what is "Unix Users" even supposed to exist?

Andras
Comment 14 Andras Korn 2009-03-30 17:51:56 UTC
Created attachment 4039 [details]
force group = +BUILTIN\Power Users
Comment 15 Andras Korn 2009-03-30 17:52:29 UTC
Created attachment 4040 [details]
force group = +Unix Users\guy
Comment 16 Karolin Seeger 2009-05-03 02:02:00 UTC
Jeremy, is that related to the "force user" issue described in bug #6291?
Comment 17 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-05-03 05:05:01 UTC
I just asked our user to try 3.3.4 packages to check whether the issue is fixed (in such case, it could likely be a duplicate of #6291).

Christian Perrier
Comment 18 Andras Korn 2009-05-03 16:55:18 UTC
(In reply to comment #17)
> I just asked our user to try 3.3.4 packages to check whether the issue is fixed
> (in such case, it could likely be a duplicate of #6291).

Sorry, still no luck. Running 3.3.4 now and the problem persists.

Andras

Ps. Christian, maybe you'd like to update the bug fields to 3.3.4 (I had also tried 3.3.3 which was b0rken in the same way, fwiw). I can't because I'm not the reporter.
Comment 19 Volker Lendecke 2009-05-03 23:51:00 UTC
I'm sorry, but this still has the "denied due to security descriptor". If you really don't have anything in your share_info.tdb, I think I need to log in to that box. This is absolutely weird, I do not see how this can happen.

Volker
Comment 20 Andras Korn 2009-05-04 03:03:42 UTC
(In reply to comment #19)
> I'm sorry, but this still has the "denied due to security descriptor".

Yes.

> If you
> really don't have anything in your share_info.tdb, I think I need to log in to
> that box. This is absolutely weird, I do not see how this can happen.

I can't give you access to this specific box, but I'm fairly sure I can reproduce this issue elsewhere. I'll get back to you when I'm done (maybe this week).

Andras
Comment 21 Andras Korn 2009-06-03 11:47:23 UTC
(In reply to comment #20)

> > If you
> > really don't have anything in your share_info.tdb, I think I need to log in to
> > that box. This is absolutely weird, I do not see how this can happen.
> 
> I can't give you access to this specific box, but I'm fairly sure I can
> reproduce this issue elsewhere. I'll get back to you when I'm done (maybe this
> week).

OK, it took a bit longer than expected, but I now have a virtualbox instance with samba and ldap inside that can be used to reproduce the problem.

I'm uploading it somewhere, but it'll take a while, it's about 600M.

I'll get back to you with the URL and suchlike when the upload is complete; this was just to let you know that I haven't forgotten. :)

Andras
Comment 22 Andras Korn 2009-06-03 19:47:17 UTC
OK, please get http://elan.rulez.org/~korn/tmp/samba-vbox.tar.bz2 (bzip compressed it to around 250M).

The size of the file is 262057706 bytes; md5: 4bcebd20a0d295beeb2cd8a6de4f0de8; sha1: 927aaaaf724a135a307d30060344e9508dda6c36.

Please tell me when I can stop hosting it.

The tar contains the contents of a ~/.VirtualBox directory, including virtualbox.xml, so be careful not to overwrite your own if you have one.

The virtual image is of a 64bit computer (to more closely match the environment where I originally experienced the problem). All passwords (root, ldap admin etc.) are "qazwsx". There is a test user called "guy" (whose password is also qazwsx); he can log in, but with the current smb.conf can't access the \\localhost\store share. If you comment out "force group" in smb.conf and reload smbd, the "guy" user can access \\localhost\store again.

The error message is, as before, "denied due to security descriptor"; the samba logs in /var/log/samba already contain at least one example, resulting from experiments with "smbclient -U guy '\\localhost\store'".

I even renamed the share_info.tdb file once and retested, with the same result.

As far as I know, the virtualbox image contains no sensitive information. You may have to adapt some configfiles (like /etc/apt/sources.list or /etc/hosts or /etc/resolv.conf) to suit your own network environment though.

I'm sorry, but I couldn't think of a much simpler way to enable you to experiment with a failing setup; if you can't run virtualbox for some reason, I can arrange for this instance to be started and accessible to you from the Internet.

Please don't hesitate to tell me if there's anything more I can do to help.

Andras
Comment 23 Volker Lendecke 2009-06-04 01:55:03 UTC
Ok, I've downloaded it. But it might take a (long) while because I only use VMware for historical reasons and not VirtualBox. I don't know if I will have a VirtualBox environment any time soon.

Sorry,

Volker
Comment 24 Andras Korn 2009-06-04 17:44:08 UTC
(In reply to comment #23)
> Ok, I've downloaded it. But it might take a (long) while because I only use
> VMware for historical reasons and not VirtualBox. I don't know if I will have a
> VirtualBox environment any time soon.

OK, would it help if I copied the contents of the filesystem out and provided a separate tar of only that? You'd need something to run it in, but even a chroot would conceivably do.
Comment 25 Volker Lendecke 2009-06-05 01:09:08 UTC
Yep, that would be great!

Volker
Comment 26 Andras Korn 2009-06-07 13:50:51 UTC
(In reply to comment #25)
> Yep, that would be great!

OK, here you are:

http://elan.rulez.org/~korn/tmp/samba-rootfs.tar.bz2

Contrary to the Virtualbox image, I didn't actually try to reproduce the problem with this system in a chroot or vserver, but I don't see why it should behave differently.

Again, please tell me when I can remove the file from the web host.

Thanks

Andras
Comment 27 Volker Lendecke 2009-06-07 16:06:19 UTC
Thanks, got it. md5sum is d7369ec2fa38bde89abef546aeda0b6c.

I'll look at it tomorrow or tuesday.

Volker
Comment 28 Volker Lendecke 2009-06-08 10:05:29 UTC
Ok, this took a while. This is very, very confusing but technically not a bug. You have ldapsam:trusted=yes with an invalid LDAP database. The primary group of user "guy", also "guy" does not have a sambaGroupMapping. This is the invalid configuration part. This leads to the token not assigning the SID for the primary group, which would be the second SID in the token. Normally, this SID is being taken by the primary unix group's SID. That SID missing means that the next SID that is normally assigned, World (S-1-1-0), takes its place. The thing the "force group" parameter does is overwrite this SID in the token. So S-1-1-0 is not part of the token. In the access checks for a share we check against the security descriptor, the default if none is there is "All rights to S-1-1-0". But as S-1-1-0 has just been overwritten by "force group", this fails.

To fix this, you could either not use "ldapsam:editposix" anymore or assign sambaGroupMapping entries to all your groups. I think without the live data I would never have found this....

Thanks,

Volker
Comment 29 Volker Lendecke 2009-06-08 10:14:33 UTC
Hmmm. Maybe we should add some protection that we don't allow login with such a broken LDAP db?

Volker
Comment 30 Volker Lendecke 2009-06-08 10:16:40 UTC
And another comment, sorry: You should either remove ldapsam:trusted or fix your LDAP db. I wrote you should remove ldapsam:editposix. That does not help. Sorry for the confusion.

Volker
Comment 31 Andras Korn 2009-06-09 05:57:33 UTC
(In reply to comment #28)

Hi,

Thanks for investigating!

> Ok, this took a while. This is very, very confusing but technically not a bug.
> You have ldapsam:trusted=yes with an invalid LDAP database. The primary group
> of user "guy", also "guy" does not have a sambaGroupMapping. This is the
> invalid configuration part. This leads to the token not assigning the SID for
> the primary group, which would be the second SID in the token. Normally, this
> SID is being taken by the primary unix group's SID. That SID missing means 

I'm either missing something or disagreeing with you, I don't know which. :) To me, the intuitive behaviour would be for Samba to join all Unix groups the connecting user is a member of, regardless of whether they have sambaGroupMappings; as I understood it so far, sambaGroupMappings are only there for the benefit of Windows. If a group has no mapping, then Windows can't see it (meaning that Samba doesn't advertise it in any way).

Why is it necessary for all groups, even the ones only used on the Unix side, to have sambaGroupMappings? If a group that has no such mapping owns a file, that ownership needn't be reported to Windows at all (as it's not necessary that a file be owned by a user as well as a group in Winland). It can be omitted from ACLs reported to Windows too. I can't currently think of a scenario that would make it necessary to insist on all Unix groups to have sambaGroupMappings.

In any case, I'd consider the misleading error message to be a bug; at least a warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping, ignoring it" should, I think, be logged.

Andras
Comment 32 Volker Lendecke 2009-06-09 06:07:01 UTC
The error message is there:

[2009/03/31 00:47:14,  5]   smbldap_search_ext: base => [ou=Group,dc=intra,dc=guy], filter => [(&(objectClass=sambaGroupMapping)(gidNumber=1000))], scope => [2]
[2009/03/31 00:47:14,  4, class=passdb]   ldapsam_getgroup: Did not find group, filter was (&(objectClass=sambaGroupMapping)(gidNumber=1000))

The problem is that we don't deny access for that user. But this would be a new bug against ldapsam:trusted.

Volker
Comment 33 John H Terpstra 2009-08-19 10:04:49 UTC
(In reply to comment #31)
> (In reply to comment #28)
> 
> Hi,
> 
> Thanks for investigating!
> 
> > Ok, this took a while. This is very, very confusing but technically not a bug.
> > You have ldapsam:trusted=yes with an invalid LDAP database. The primary group
> > of user "guy", also "guy" does not have a sambaGroupMapping. This is the
> > invalid configuration part. This leads to the token not assigning the SID for
> > the primary group, which would be the second SID in the token. Normally, this
> > SID is being taken by the primary unix group's SID. That SID missing means 
> 
> I'm either missing something or disagreeing with you, I don't know which. :) To
> me, the intuitive behaviour would be for Samba to join all Unix groups the
> connecting user is a member of, regardless of whether they have
> sambaGroupMappings; as I understood it so far, sambaGroupMappings are only
> there for the benefit of Windows. If a group has no mapping, then Windows can't
> see it (meaning that Samba doesn't advertise it in any way).
> 
> Why is it necessary for all groups, even the ones only used on the Unix side,
> to have sambaGroupMappings? If a group that has no such mapping owns a file,
> that ownership needn't be reported to Windows at all (as it's not necessary
> that a file be owned by a user as well as a group in Winland). It can be
> omitted from ACLs reported to Windows too. I can't currently think of a
> scenario that would make it necessary to insist on all Unix groups to have
> sambaGroupMappings.
> 
> In any case, I'd consider the misleading error message to be a bug; at least a
> warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping,
> ignoring it" should, I think, be logged.
> 
> Andras
> 

Andras,

UNIX groups that have no members who are both UNIX and Samba/Windows users do not need to be mapped to Windows groups.  However, all UNIX groups of which Windows users are members require a Windows group mapping.

Given that there are usually not many UNIX groups, why not map all of them so that you will not get caught out at a later time.  Volker's advice is good advice.

- John T.
Comment 34 Andras Korn 2009-08-30 05:50:04 UTC
(In reply to comment #33)
> (In reply to comment #31)
> > (In reply to comment #28)
> > 
> > I'm either missing something or disagreeing with you, I don't know which. :) To
> > me, the intuitive behaviour would be for Samba to join all Unix groups the
> > connecting user is a member of, regardless of whether they have
> > sambaGroupMappings; as I understood it so far, sambaGroupMappings are only
> > there for the benefit of Windows. If a group has no mapping, then Windows can't
> > see it (meaning that Samba doesn't advertise it in any way).
> > 
> > Why is it necessary for all groups, even the ones only used on the Unix side,
> > to have sambaGroupMappings? If a group that has no such mapping owns a file,
> > that ownership needn't be reported to Windows at all (as it's not necessary
> > that a file be owned by a user as well as a group in Winland). It can be
> > omitted from ACLs reported to Windows too. I can't currently think of a
> > scenario that would make it necessary to insist on all Unix groups to have
> > sambaGroupMappings.
> > 
> > In any case, I'd consider the misleading error message to be a bug; at least a
> > warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping,
> > ignoring it" should, I think, be logged.
> > 
> > Andras
> > 
> 
> UNIX groups that have no members who are both UNIX and Samba/Windows users do
> not need to be mapped to Windows groups.  However, all UNIX groups of which
> Windows users are members require a Windows group mapping.

I understand that this is how things are, but not why, given the above. Windows just needn't know about the groups that have no windows mappings; they could still be used on the Unix side.

> Given that there are usually not many UNIX groups, why not map all of them so
> that you will not get caught out at a later time.  Volker's advice is good
> advice.

I can certainly map all of them, which works around this limitation. That this is necessary surprises me though, for the reasons outlined above.

Also, I think it might actually be useful to hide some Unix groups from Windows.

For example, suppose I have a Unix directory, a subdirectory of a share, owned by group "foo", with posix ACLs like d:g:foo:rwx,g:foo:rwx. Also suppose some of my users (the Unix users their Windows accounts are mapped to) are members of group foo. If Samba worked the way I had assumed it did, then group foo wouldn't be visible to any Windows based access control manipulation tools; thus, the ability of group foo to read and write this directory couldn't be removed by Windows users even by accident, resulting in a sort of mandatory access control. There may be other means to this end, but this is straightforward in the sense that no magic at all is involved on the Unix side and no fancy Samba configuration is needed.

Andras
Comment 35 Andras Korn 2009-08-30 06:01:44 UTC
(In reply to comment #34)
> Also, I think it might actually be useful to hide some Unix groups from
> Windows.

(But I realise the query optimisations related to ldapsam:trusted may make this unfeasible.)