Red Hat Bugzilla – Bug 969651
sudo: unable to set runas group vector: Invalid argument
Last modified: 2015-02-17 10:24:57 EST
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.
Why do you have winbind configured if you don't need it? Have you correctly configured winbind?
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.
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): ****** -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 ****** -1 -1
Additionally the command: id root Produces valid information ending in this invalid information: ,4294967295,4294967295,4294967295,4294967295,4294967295,4294967295 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: ,0(root)
Could you please paste your your smb.conf. For more details please read: https://www.samba.org/~asn/reporting_samba_bugs.txt
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.
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.
[global] 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.
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
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.
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.