((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))

[Jim Knoble]

Circa 2003-02-12 15:05:20 -0500 dixit James Dennis:

: Hey everyone,
: 
: After discussing the AllowGroups I think I've discovered a bug.
: 
: The system is a solaris 8 system and the problem is that when I use 
: AllowGroups with no AllowUsers args, the proper actions happen. Same 
: with AllowUsers and no AllowGroups. When I try to combine the two, none 
: of the Allow directives seem to take.
: 
: Is it just me or maybe a bug?

Maybe a little of both.

Testing under OpenBSD-3.2:

  $ ssh -V
  OpenSSH_3.5, SSH protocols 1.5/2.0, OpenSSL 0x00907003

with the following users:

  # useradd -m -G users blah
  # useradd -m -G users haha
  # egrep '(blah|haha)' /etc/passwd /etc/group
  /etc/passwd:blah:*:1021:1021::/home/blah:/bin/ksh
  /etc/passwd:haha:*:1022:1022::/home/haha:/bin/ksh
  /etc/group:users:*:10:,blah,haha
  /etc/group:blah:*:1019:blah
  /etc/group:haha:*:1020:haha
  # 

gives the following results:

                                            Users successfully log in:
  Condition                                 blah    haha    root

  no Allow*                             =>  yes     yes     yes
  AllowUsers blah                       =>  yes     no      no
  AllowUsers haha                       =>  no      yes     no
  AllowUsers root                       =>  no      no      yes
  AllowGroups users                     =>  yes     yes     no
  AllowGroups users, AllowUsers root    =>  no      no      no

The last one is what's surprising.  Here's what the sshd log has to say
(at LogLevel VERBOSE, with timestamps removed to conserve space):

----------------
Received SIGHUP; restarting.
Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
Connection from 127.0.0.1 port 32492
User blah not allowed because not listed in AllowUsers
input_userauth_request: illegal user blah
Failed none for illegal user blah from 127.0.0.1 port 32492 ssh2
Failed publickey for illegal user blah from 127.0.0.1 port 32492 ssh2
[...]
Failed password for illegal user blah from 127.0.0.1 port 32492 ssh2
[...]
Disconnecting: Too many authentication failures for blah
Connection from 127.0.0.1 port 40621
User haha not allowed because not listed in AllowUsers
input_userauth_request: illegal user haha
Failed none for illegal user haha from 127.0.0.1 port 40621 ssh2
Failed publickey for illegal user haha from 127.0.0.1 port 40621 ssh2
[...]
Failed password for illegal user haha from 127.0.0.1 port 40621 ssh2
[...]
Disconnecting: Too many authentication failures for haha
Connection from 127.0.0.1 port 35381
User root not allowed because none of user's groups are listed in AllowGroups
input_userauth_request: illegal user root
Failed none for illegal user root from 127.0.0.1 port 35381 ssh2
Failed publickey for illegal user root from 127.0.0.1 port 35381 ssh2
[...]
Failed password for illegal user root from 127.0.0.1 port 35381 ssh2
[...]
Disconnecting: Too many authentication failures for root
----------------

Seems as if sshd requires that a user be in:

  AllowUsers <set-intersection> AllowGroups

instead of:

  AllowUsers <set-union> AllowGroups

in order not to be an "illegal user".  That's certainly not what i
expected.  If i need to deny certain group members, i would expect to
do the following:

  DenyUsers blah
  AllowGroups users
  [implicit DenyUsers *]

or:

  DenyGroups wheel
  AllowGroups users
  [implicit DenyUsers *]

I would also expect that:

  AllowUsers root
  AllowGroups users
  [implicit DenyUsers *]

would allow all three of blah, haha, and root.  That is, i expect a
first-match allow/deny, in the order listed in the file, and that there
is exactly one implicit 'DenyUsers *' (if any Allow* directives appear)
or 'AllowUsers *' (if any Deny* directives appear, and no Allow*
directives appear), which appears at the very bottom of the list.  That
is:

  DenyGroups users
  DenyUsers root
  [implicit AllowUsers *]

or:

  DenyUsers root
  AllowGroups wheel staff
  [implicit DenyUsers *]

Alternatively, if sshd were to do a last-match instead of a
first-match, then the implicit 'AllowUsers *' or 'DenyUsers *' rule
would go at the top, and the order would be reversed, e.g.:

  [implicit DenyUsers *]
  AllowGroups wheel staff
  DenyUsers root

Either way would work better than the current surprising behavior
(although i prefer first-match ACLs rather than last-match ones).
Anyone else care to comment?

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
"I am non-refutable."  --Enik the Altrusian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 256 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030212/9ab529ce/attachment.bin