openssh bugs - Feb 2006 - [Bug 1165] 'groups' command fails on AIX when logged in as root user via SSH.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165

           Summary: 'groups' command fails on AIX when logged in as root
                    user via SSH.
           Product: Portable OpenSSH
           Version: 4.2p1
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: major
          Priority: P2
         Component: Miscellaneous
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: kramgautham at yahoo.com
                CC: kramgautham at yahoo.com


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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Miscellaneous               |sshd




------- Comment #1 from dtucker at zip.com.au  2006-02-28 23:23 -------
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)?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165





------- Comment #2 from kramgautham at yahoo.com  2006-03-01 17:19 -------
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). 




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165





------- Comment #3 from dtucker at zip.com.au  2006-03-01 17:34 -------
(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?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165





------- Comment #4 from kramgautham at yahoo.com  2006-03-01 22:27 -------
# 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. 




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1165





------- Comment #5 from dtucker at zip.com.au  2006-03-01 23:08 -------
(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




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.