Eric Sisson
2008-Dec-16 19:48 UTC
Request change to file match.c, function match_pattern_list
Greetings, This request is in the grey area between a bug report and an enhancement request. Request ------- Please apply the following diff (or something functionally similar) to file ``match.c'' in OpenSSH-5.1p1: 161a162,164 > } else { > if (negated) > got_positive = 1; /* Negative match, negated = Positive */ In case the lines above wrapped in the email transmission, the diff is attached as a .gz file. -------------- next part -------------- A non-text attachment was scrubbed... Name: match.c.diff.gz Type: application/x-gzip Size: 104 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081216/fe35d5b5/attachment.bin -------------- next part -------------- Justification ------------- On a system running Red Hat Enterprise Linux 4, I wanted to use a configuration of the following form in sshd_config: DenyUsers oracle@!localhost.localdomain that would prevent user ``oracle'' from logging into the host from any host except the host itself (localhost). Rephrased, I want to allow logins to user ``oracle'' only by users who already are logged into the same host that has user ``oracle''. The above construct fails in OpenSSH, and I traced the failure to the absence of code handling this case in an ``if'' statement (that checks the result of function ``match_pattern'') near the end of the main ``for'' loop in function ``match_pattern_list'' in file ``match.c''. The diff above is an example of code to handle this case. The meaning of this new code is the following: - If a string fails to match the subpattern of the configuration, then execution will flow into ``else'' branch. - Normally, the failure of a match is a failure (``got_positive'' retains its initialized value of zero). - However, where a failure is desired (the ``!'' in the specification subpattern), then the occurrence of a failure is a ``success'', so ``got_positive'' should be set to one. Initially, I was working with OpenSSH-3.9p1, but I see that the code remains consistent through OpenSSH-5.1p1, so I am reporting this change request relative to the newer version. Respectfully, Eric Sisson -- Eric M. Sisson, Systems Analyst III email: ems at mdacc.tmc.edu Clinical Research Information Systems - Box 237 voice: 713-792-2629 University of Texas M. D. Anderson Cancer Center fax: 713-745-0615 1515 Holcombe Boulevard Houston, Texas 77030-4009
Jim Knoble
2008-Dec-17 22:41 UTC
Request change to file match.c, function match_pattern_list
Circa 2008-12-16 14:48 dixit Eric Sisson: : This request is in the grey area between a bug report and an : enhancement request. Probably best to file this in the OpenSSH Bugzilla: http://www.openssh.com/report.html (and follow the "Bugzilla" link). This may avoid your report getting lost amid mailing list noise. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+
Iain Morgan
2008-Dec-17 23:34 UTC
Request change to file match.c, function match_pattern_list
On Tue, Dec 16, 2008 at 13:48:36 -0600, Eric Sisson wrote:> > On a system running Red Hat Enterprise Linux 4, I wanted to use a > configuration of the following form in sshd_config: > > DenyUsers oracle@!localhost.localdomain >You might want to try this instead: DenyUsers oracle@*,!localhost.localdomain -- Iain Morgan
Reasonably Related Threads
- [Bug 1546] New: sshd_config DenyUsers does not recognize negated host properly
- [PATCH 2/2] Cygwin: implement case-insensitive Unicode user and group name matching
- [PATCH 0/2] Cygwin: allow user and group case-insensitive Unicode strings
- ssh-keygen -R is case-sensitive, but should not be
- more flexible AllowUsers/DenyUsers syntax