Bug 969651 - sudo: unable to set runas group vector: Invalid argument
sudo: unable to set runas group vector: Invalid argument
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Guenther Deschner
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-01 09:06 EDT by David Woodhouse
Modified: 2015-02-17 10:24 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-17 10:24:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2013-06-01 09:06:53 EDT
Sudo recently stopped working, giving the following error message:
sudo: unable to set runas group vector: Invalid argument

Reverting to sudo-1.8.6p3-2.fc18.x86_64.rpm does not appear to fix this.
Comment 2 Andreas Schneider 2013-06-03 08:08:14 EDT
Why do you have winbind configured if you don't need it? Have you correctly configured winbind?
Comment 3 David Woodhouse 2013-06-03 10:07:50 EDT
It was working well enough to let me log in using my Active Directory password, and then it would keep my Kerberos keys up to date. I'm not sure why root is now in some additional groups, or why it isn't able to actually *join* those groups.
Comment 4 prosigma 2013-07-30 15:44:47 EDT
I believe I can replicate this behavior on Fedora 18 3.8.8-202.fc18.x86_64.
I have Samba4 winbindd to connect to a Microsoft AD with RFC2307 schema added.
It is returning information (some invalid) from all the groups to which a specific user is a member not just the groups which have RFC2307 attributes.
This was not previously an issue and does not appear to be an issue in:
RedHat or CentOS.

Confirmation of Samba 4:
winbindd --version produces:
Version 4.0.7

Demonstration of issue: wbinfo --user-groups *username*

Should return something like this (2 valid numbers redacted):

Instead produces (2 valid numbers redacted):
Comment 5 prosigma 2013-07-30 15:51:55 EDT
Additionally the command: id root

Produces valid information ending in this invalid information:
Pretty similar to comment 1 from David Woodhouse.

That incorrect information does not appear on a working host instead at the end of the line you see this instead:
Comment 6 Andreas Schneider 2013-07-31 07:33:31 EDT
Could you please paste your your smb.conf.

For more details please read:

Comment 8 prosigma 2013-07-31 16:42:32 EDT
There are some pieces of information listed on the document: "SAMBA BUG REPORTING" as linked above I am willing to provide but not for public record.  Feel free to contact me in private I have access to testing resources as well.
Comment 10 prosigma 2013-08-01 08:34:55 EDT
Will test today.
This actually works on a large number of hosts.
However just because it works does not mean it is entirely correct.

Using AD on Windows 2008 R2.
Comment 13 prosigma 2013-08-01 20:01:49 EDT
 workgroup                         = REDACT
 security                          = ads
 winbind use default domain        = true

* Everything below from Andreas Schneider - RedHat Bug 969651

 passdb backend                    = tdbsam
 idmap config * : range            = 1000000-9999999

 idmap config REDACT : backend     = ad
 idmap config REDACT : schema_mode = rfc2307
 idmap config REDACT : range       = 100-999999

 template shell                    = /bin/bash
 winbind nss info                  = rfc2307

I still have the same problem at this point on impacted hosts.
I haven't tested this adequately yet on hosts that never exhibited this issue.
Comment 14 Andreas Schneider 2013-08-02 05:02:01 EDT
If you have Windows 2008 R2 you should use SFU and not rfc2307.

If this still doesn't work please explain how to reproduce it, see: https://www.samba.org/~asn/reporting_samba_bugs.txt
Comment 15 prosigma 2013-08-02 13:54:08 EDT
We do have a Windows 2008 R2 AD infrastructure.

Just tried every combination I could think of: rfc2307, sfu, sfu20
In these 2 settings:
 idmap config REDACT : schema_mode = rfc2307
 winbind nss info                  = rfc2307

So I tried: rfc2307 in both, sfu in both and sfu20 in both settings.
Plus the less obvious combinations.
I rebooted each test and checked both the results and that smb.conf was as expected.

This did not prevent getting AD data from the schema but it did not fix the issue on the impacted systems either.

At this point of the bug reporting process I need to explain that I was not present at the time Fedora 18 or the Windows 2008 R2 AD was originally tested or during the implementation.  The involved AD here is neither simple nor small and outside this testing it is in succesful production operation without issue for the hosts other than Fedora 18.

I will comply with the request to provide directions to replicate the impacted environment on the Windows side but I need to erect a test environment and gather the information.  Not to mention reduce the complexity down to the most direct way to demonstrate the issue.  This is likely to take several days at least.  I will be back when I can meet this request.
Comment 16 Fedora End Of Life 2015-01-09 13:17:18 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 17 Fedora End Of Life 2015-02-17 10:24:57 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.