Bug 10835 - winbind not reporting group membership on FreeBSD due to missing getgroupmembership implementation
Summary: winbind not reporting group membership on FreeBSD due to missing getgroupmemb...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: All FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
: 4850 9715 (view as bug list)
Depends on: 4850
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-24 13:52 UTC by Tristram Scott
Modified: 2015-02-22 18:39 UTC (History)
6 users (show)

See Also:


Attachments
0001-nss_winbind-add-getgroupmembership-for-FreeBSD.patch (5.17 KB, patch)
2014-10-21 07:46 UTC, Björn Jacke
vl: review+
bjacke: review? (metze)
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tristram Scott 2014-09-24 13:52:17 UTC
Hi,

we have a problem where it seems that winbind is not reporting group members.  Here, with Version 4.2.0pre1-GIT-f27d8b8, it works:
[root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# smbd -V
Version 4.2.0pre1-GIT-f27d8b8
[root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# wbinfo --group-info dept-specialcollections-digitallibrary
dept-specialcollections-digitallibrary:x:14745:mmp28,gy219,hej23,jlf44,acc60,cms93
[root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# 

Here, with Version 4.2.0pre1-GIT-5d22bcf it does not work:

root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # smbd -V
Version 4.2.0pre1-GIT-5d22bcf
root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # wbinfo --group-info dept-specialcollections-digitallibrary
dept-specialcollections-digitallibrary:x:14745:
root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # wbinfo -r hej23
14203
10513
14755
11109
14745
14835
11107 
14775 
50001
root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # 

Notice that it does not report the group members, but it does actually know that the user is a member of the group in question.

The system if FreeBSD 10.0:
root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # uname -a
FreeBSD stor-pri-01.ds.lib.cam.ac.uk 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun  3 13:14:57 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

The problem also presents itself with 8c3e0f8.

The above is all on the exact same machine with the same smb.conf.  We see the same behaviour across three different FreeBSD boxes.  The same result comes out of using getent group, but then, I think that is expected to exactly match what wbinfo states.

This is the nsswitch file:

root@stor-pri-01:/ # cat /etc/nsswitch.conf 
#
# nsswitch.conf(5) - name service switch configuration file
# $FreeBSD: release/10.0.0/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z dougb $
# 
group: files winbind
group_compat: nis
hosts: files dns
networks: files
passwd: files winbind
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
  
root@stor-pri-01:/ # 

This is the smb.conf

[root@stor-pri-01 /]# cat /opt/samba4/etc/smb.conf 
[global]
    workgroup = CUL
    server string = Samba Server Version %v
    security = ads
    realm = AD.LIB.CAM.AC.UK
    domain master = no
    local master = no
    preferred master = no
 
    idmap config * : backend = tdb
    idmap config * : range = 50000-99999
    idmap config CUL : backend = rid
    idmap config CUL : range = 10000-49999

    kernel change notify = no

    winbind separator = +
    winbind enum users = yes
    winbind enum groups = yes
    winbind use default domain = yes
    winbind nested groups = yes
    winbind trusted domains only = no
    winbind nss info = rfc2307
    winbind refresh tickets = yes
    template homedir = /home/%U
    template shell = /bin/sh
    nsupdate command = /usr/local/bin/samba-nsupdate -g
 
    client use spnego = yes
    client ntlmv2 auth = yes
    encrypt passwords = yes
    restrict anonymous = 2
    log file = /var/log/samba4/log.%m
    max log size = 500
#    log level = 3

    unix extensions = no
    nt acl support  = yes
    inherit acls    = no
    map acl inherit = yes

    printing = bsd
    printcap name = /dev/null

 
#============================ Share Definitions ==============================
 
[testshare]
    comment = Test share
    path = /samba/testshare
    browseable = yes
    read only = no
    valid users = @"CUL+Domain Users"
    vfs objects = zfsacl shadow_copy2
    map acl inherit = Yes
    store dos attributes = Yes
    shadow: snapdir = .zfs/snapshot
    shadow: sort = desc
    shadow: localtime = yes
    shadow: format = %Y%m%d
  

[root@stor-pri-01 /]#
Comment 1 Björn Jacke 2014-09-24 19:04:36 UTC
this is because winbind expand groups is set to 0 now. This is intentionally and not a bug.

See WHATSNEW.txt or - as you use an unreleased version - you might also have a look at commit 98426ad467fa64975bd9e6aa32530a2dde719035.

I guess this bug report will get a lot of duplicates. Couldn't you wait for a nicer bug number than 10835 ? ;-)
Comment 2 Tristram Scott 2014-09-26 09:17:57 UTC
Thanks for quickly following up on that.  I have confirmed that setting winbind expand groups = 1 resolves the issue.

I do have a question, though.  In the commit message 98426ad467fa64975bd9e6aa32530a2dde719035 it states:

    Only some broken applications calculate the group memberships of
    users by traversing groups, such applications will require
    "winbind expand groups = 1".

It would seem, on the face of it, that at least on FreeBSD, getent group is one of those broken applications.  The reason this came to our attention is that a user attempted to rename a file which they did not own, but that was owned by a group they are a member of.

So my question:  Is this an indication that FreeBSD is broken in this respect, or is it just that we have failed to configure it and samba correctly?

Regards, and thanks again for the help.

Tristram
Comment 3 Stefan Metzmacher 2014-09-29 14:37:49 UTC
(In reply to comment #2)
> Thanks for quickly following up on that.  I have confirmed that setting winbind
> expand groups = 1 resolves the issue.
> 
> I do have a question, though.  In the commit message
> 98426ad467fa64975bd9e6aa32530a2dde719035 it states:
> 
>     Only some broken applications calculate the group memberships of
>     users by traversing groups, such applications will require
>     "winbind expand groups = 1".
> 
> It would seem, on the face of it, that at least on FreeBSD, getent group is one
> of those broken applications.  The reason this came to our attention is that a
> user attempted to rename a file which they did not own, but that was owned by a
> group they are a member of.
> 
> So my question:  Is this an indication that FreeBSD is broken in this respect,
> or is it just that we have failed to configure it and samba correctly?

What is the exact problem that you have?
Is it only the 'wbinfo --group-info' (getent group) output?
Or do you have more problems?
Comment 4 Tristram Scott 2014-09-29 15:15:08 UTC
The problem is that the underlying operating system does not see that users are in groups which are defined for our Windows domain.   For example, we have a user, hej23, who is a member of dept-specialcollections-digitalcontent.  In a folder which is owned by that group, with group rwx, it should be possible to create a file:

$ id
uid=14203(hej23) gid=10513(domain users) groups=10513(domain users)
$ ls -la
total 43
drwxrwxr-x  5 root   dept-specialcollections-digital  5 Sep 29 14:58 .
drwxr-xr-x  3 root   wheel                            3 Sep  5 13:49 ..
drwxrwxr-x  2 ts551  dept-specialcollections-digital  2 Sep  5 13:52 t1
drwxrwxr-x+ 3 ts551  dept-specialcollections-digital  3 Sep  5 13:55 t2
drwxrwxr-x  2 hej23  dept-specialcollections-digital  2 Sep 29 14:58 t3
$ getfacl .
# file: .
# owner: root
# group: dept-specialcollections-digitalcontent
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
         everyone@:r-x---a-R-c--s:------:allow
$ touch f1
touch: f1: Permission denied

I then set winbind expand groups = 2, grab a new shell, and the file creation works.

$ testparm | grep expand
Load smb config files from /opt/samba4/etc/smb.conf
Processing section "[testshare]"
Loaded services file OK.
'winbind separator = +' might cause problems with group membership.

Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

	winbind expand groups = 2
root@stor-pri-01:/samba/testshare # su hej23
$ touch f1
$ id
uid=14203(hej23) gid=10513(domain users) groups=10513(domain users),12861(dept-specialcollections-digitalcontent),14745(dept-specialcollections-digitallibrary),14755(dept-cdd-journals),14775(dept-cdd),14777(dept-specialcollections),14835(project-voyagerreports)
$ ls -la f1
-rw-r--r--  1 hej23  dept-specialcollections-digital  0 Sep 29 15:06 f1
$ 

So, with winbind expand groups = 0, group membership really does not work for us at all.

We understand that we can (and should) set winbind expand groups = 1 or higher, but was it really your expectation that the above operations would fail?
Comment 5 Björn Jacke 2014-09-29 15:34:34 UTC
I guess you did not authenicate but you su'ed to the user instead, right? Users that authenticate get the group memberships. Doing "su - someuser" as root is not legit. This is working for local passwd users/groups but not for users that come from external, where the local system root is not a priviledged authority. Without authentication there is no way to fully impersonate a domain user.
Comment 6 Tristram Scott 2014-09-29 15:53:43 UTC
(In reply to comment #5)
> I guess you did not authenicate but you su'ed to the user instead, right? Users
> that authenticate get the group memberships. Doing "su - someuser" as root is
> not legit. This is working for local passwd users/groups but not for users that
> come from external, where the local system root is not a priviledged authority.
> Without authentication there is no way to fully impersonate a domain user.

Okay, I take that.  Yes, for hej23, I did su.  However, this time I have logged in as myself, and I see the same problem:

stoat:~ ts551$ ssh stor-pri-01 
Password: 
X11 forwarding request failed on channel 0
Last login: Mon Sep 29 14:53:58 2014 from 10.10.254.254
FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun  3 13:14:57 UTC 2014


$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel),10512(domain admins),10572(denied rodc password replication group),11104(dnsadmins),11107(dept-digitalservices),11108(dept-digitalservices-operations),11116(dhcp administrators),14780(local desktop administrators),14887(_ops_sudoers),14888(joke_sudoers)
$ cd /samba/testshare/t4
$ ls -la
total 17
drwxrwxr-x  2 hej23  dept-digitalservices-operations  2 Sep 29 15:43 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
$ getfacl .
# file: .
# owner: hej23
# group: dept-digitalservices-operations
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
         everyone@:r-x---a-R-c--s:------:allow
$ touch f1
$ ls -la f1
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ ^DConnection to stor-pri-01 closed.

Then, with winbind expand groups = 0:

stoat:~ ts551$ ssh stor-pri-01 
Password: 
X11 forwarding request failed on channel 0
Last login: Mon Sep 29 15:46:09 2014 from 10.10.254.254
FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun  3 13:14:57 UTC 2014


$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ cd /samba/testshare/t4/
$ ls -la
total 18
drwxrwxr-x  2 hej23  dept-digitalservices-operations  3 Sep 29 15:45 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ touch f2
touch: f2: Permission denied
$ 

My account on this box is not local, it comes via AD.

Regards,

Tristram
Comment 7 Björn Jacke 2014-09-29 16:06:26 UTC
great that you can confirm that with authentication it worked there. for that other server well, you use the highly deprecated winbind use default domain option obviously, otherwise your domains users could not be in the group 0(wheel). I don't know what other config flaws there might be. I fear analyzing the configuration issues of several servers is beyond of this bug report.
Comment 8 Tristram Scott 2014-09-29 16:17:31 UTC
Hi Bjorn,

no, I have not confirmed it working with authentication.

What I confirmed is the same mode of failure when using an authenticating user (ts551) as when I did an su to hej23.  

All of these tests have been against the same machine.  

Regards,

Tristram
Comment 9 Volker Lendecke 2014-09-30 08:57:41 UTC
(In reply to comment #8)
> Hi Bjorn,
> 
> no, I have not confirmed it working with authentication.
> 
> What I confirmed is the same mode of failure when using an authenticating user
> (ts551) as when I did an su to hej23.  
> 
> All of these tests have been against the same machine.  
> 
> Regards,
> 
> Tristram

What kind of auth do you use? The way to make it work is to use something like pam_winbind. To simulate it, you should do a

wbinfo -a <username>

and successfully log in. After that, a fresh login/su should work.
Comment 10 Tristram Scott 2014-09-30 09:07:38 UTC
Hi Volker,

we are using pam_winbind for authentiaction on this box.  The sshd config is below.  The system one is below that.


$ cat /etc/pam.d/sshd | grep -v '#'

auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth            sufficient      pam_winbind.so          try_first_pass require_membership_of=S-1-5-21-2841595342-2583126837-4265527824-4887 debug 
auth		requisite	pam_opieaccess.so	no_warn allow_local
auth		required	pam_unix.so		no_warn try_first_pass


account		sufficient	pam_winbind.so		try_first_pass debug 
account		required	pam_nologin.so
account		required	pam_login_access.so
account		required	pam_unix.so


session         required        pam_winbind.so          debug 
session		required	pam_permit.so
session		required	/usr/local/lib/pam_mkhomedir.so	umask=0077


password	sufficient	pam_winbind.so		debug 
password	required	pam_unix.so		no_warn try_first_pass
$ cat /etc/pam.d/system | grep -v '#'

auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth		sufficient	pam_winbind.so		try_first_pass debug 
auth		requisite	pam_opieaccess.so	no_warn allow_local
auth		required	pam_unix.so		no_warn try_first_pass nullok

account		sufficient	pam_winbind.so		try_first_pass debug 
account		required	pam_login_access.so
account		required	pam_unix.so

session		required	pam_winbind.so		debug 
session		required	pam_lastlog.so		no_fail
session		required	/usr/local/lib/pam_mkhomedir.so	umask=0022

password	sufficient	pam_winbind.so		debug 
password	required	pam_unix.so		no_warn try_first_pass
$ 
 
I have done the wbinfo -a here, but I am not sure what we learn from it.  My understanding is that the pam_winbind is achieving the same thing.  By the way, without the pam_winbind entries above, I am not able to log in to this machine, so it certainly does seem to be using it.

$ wbinfo -a ts551
Enter ts551's password: 
plaintext password authentication succeeded
Enter ts551's password: 
challenge/response password authentication succeeded
$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ su ts551
$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ cd /samba/testshare/t4/
$ ls -la
total 18
drwxrwxr-x  2 hej23  dept-digitalservices-operations  3 Sep 29 15:45 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ touch f2
touch: f2: Permission denied
$
Comment 11 Volker Lendecke 2014-09-30 09:24:38 UTC
Thanks for the retry!

Reopening, we need to implement the "getgroupmembership" nss function in winbind_nss_freebsd.c to make this work under FreeBSD.
Comment 12 Stefan Metzmacher 2014-09-30 11:01:59 UTC
(In reply to comment #11)
> Thanks for the retry!
> 
> Reopening, we need to implement the "getgroupmembership" nss function in
> winbind_nss_freebsd.c to make this work under FreeBSD.

Can we just copy and paste it from nsswitch/winbind_nss_netbsd.c ?
Comment 13 Björn Jacke 2014-09-30 14:20:40 UTC
wouldn't it be better if the freebsd/netbsd code would be merged instead of doing more code copying in between those modules?
Comment 14 Timur Bakeyev 2014-09-30 15:22:35 UTC
(In reply to comment #13)
> wouldn't it be better if the freebsd/netbsd code would be merged instead of
> doing more code copying in between those modules?

Not sure, what are you guys trying to reimplement, for ages I couldn't get audit of the FreeBSD ports code by any of the Samba developers. As for this function, it was added to samba 3.6 port few years ago and current samba 4.1 port has it as well:

http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup
Comment 15 Volker Lendecke 2014-09-30 15:25:14 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > wouldn't it be better if the freebsd/netbsd code would be merged instead of
> > doing more code copying in between those modules?
> 
> Not sure, what are you guys trying to reimplement, for ages I couldn't get
> audit of the FreeBSD ports code by any of the Samba developers. As for this
> function, it was added to samba 3.6 port few years ago and current samba 4.1
> port has it as well:
> 
> http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup

Perfect :-)

Problem solved...
Comment 16 Jeremy Allison 2014-09-30 15:39:24 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > wouldn't it be better if the freebsd/netbsd code would be merged instead of
> > doing more code copying in between those modules?
> 
> Not sure, what are you guys trying to reimplement, for ages I couldn't get
> audit of the FreeBSD ports code by any of the Samba developers. As for this
> function, it was added to samba 3.6 port few years ago and current samba 4.1
> port has it as well:
> 
> http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup

We're not ignoring you Timur, it's just that you need to propose each change as a patch on samba-technical to get them upstream.

Apologies if you already did this *and* got ignored :-).

Please post them (or post them again), and we'll try and do better.

Cheers,

Jeremy.
Comment 17 Björn Jacke 2014-10-21 07:46:56 UTC
Created attachment 10360 [details]
0001-nss_winbind-add-getgroupmembership-for-FreeBSD.patch

this patch is for the 4.1 and 4.2 branch
Comment 18 Karolin Seeger 2014-10-26 20:36:13 UTC
Pushed to autobuild-v4-[1|2]-test.
Comment 19 Karolin Seeger 2014-10-29 19:56:21 UTC
Pushed to both branches.
Closing out bug report.

Thanks!
Comment 20 Björn Jacke 2014-10-30 08:30:35 UTC
*** Bug 4850 has been marked as a duplicate of this bug. ***
Comment 21 Björn Jacke 2015-02-22 18:39:55 UTC
*** Bug 9715 has been marked as a duplicate of this bug. ***