The 'groups' command fails on AIX when the user is logged in as root through SSH. The same does not fail when the root user is logged in via telnet session. I did not observe this bug on Solaris. The command 'groups root' gives the correct information. I believe that 'groups' command internally calls 'id -Gn' command. Execution of 'id -Gn' also fails. However, 'su -','su root' and 'su' commands if executed on the AIX machine after having logged in, the 'groups' command works fine. Actually, I found this issue while trying to execute a file which failed to run. The error "User not authorized to perform command" was seen while trying to execute. The user was not permitted to execute by the file itself. I wanted to understand why the permission problem was seen on AIX when logged in via SSH. Thanks in advance.
What groups do you see and what do you expect to see? (substitute the groups names if you like but please do it consistently). What version of AIX is this, and how was OpenSSH built? Did you use any build-time options, eg --with-pam? Do you have any nonstandard AIX LAM modules (eg NIS or LDAP)?
The 'groups' command returns a new blank line. example # #groups # #groups root system # AIX version 4. OpenSSH was configured with '--wit-pam' option. No other buildtime option was used. I don't have any non-standard LAM modules. This observation was made on 'root' user ( local admin).
(In reply to comment #2) > The 'groups' command returns a new blank line. That's odd. Sounds like the supplementary gid list is empty but I would have thought the primary gid would be listed. > AIX version 4. OpenSSH was configured with '--wit-pam' option. No other > buildtime option was used. "AIX version 4" covers a lot of ground. Which exact version is it? (ie what do "oslevel" and "oslevel -r" give? depending on how old it is the latter may not work). Also, the first version of AIX with a supported PAM implementation was 5.2. (5.1 shipped with some of the bits and IBM backported the rest but it's not supported by them.) There's an unsupported port of LinuxPAM to AIX 4.3.x but it's, well, really unsupported. Does building without --with-pam work as expected?
# oslevel -r 4330-01 # oslevel 4.3.3.0 # LibPAM version is 0.78 So you are indicating that this is expected behaviour/design intent of AIX and SSH put together. Is there a way forward ? Thanks.
(In reply to comment #4) > # oslevel -r > 4330-01 OK, well AIX 4.3.3 has been unsupported by IBM since (from memory) the start of last year. And the last AIX ML was 11. So your platform is seriously unsupported. > LibPAM version is 0.78 That looks like a LinuxPAM version. So all up you have an EOLed OS version with a very old maintenance level and an unsupported third-party PAM library. > So you are indicating that this is expected behaviour/design intent of AIX and > SSH put together. No, there's no intent at all. What you have is completely unsupported; if it works for you then great, otherwise I am afraid you are on your own. > Is there a way forward ? Your options seem to be: a) build without PAM, assuming that works as expected. (It does on AIX 5.1 here.) If the problem persists without PAM then we may be able to help you. b) assuming the problem is within the PAM library, try to figure out how to fix it. From a quick grep of LinuxPAM source of that vintage, the most likely candidate is pam_group.c, although this might be different if you have different modules. If you add a call to getgroups to the end of my pam test harness [1] (adding "system("groups");" ought to do) and running the result as root will prove whether or not your PAM stack is at fault). If this exhibits the same problem then the provider of the PAM stack may be able to help. c) By coincidence, I also have an old patch[2] for LinuxPAM that might or might not be the underlying cause but if not then I'm afraid we can't help you. [1] http://www.zip.com.au/~dtucker/patches/#pamtest [2] http://www.zip.com.au/~dtucker/patches/linux-pam-0.77-pam_group_noreset.patch
Closing bug. Unfortunately we can't support third-party PAM stacks. Please reopen if you can reproduce without the third-party PAM stack (eg UsePAM=no, or rebuilt without PAM).
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.