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
Maybe Matching 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