how to set env var by telnet port no
Richard Karl Getchell
port 23 and also port 7023. Next, I want to have /etc/profile set an
environment variable depending on which of those two ports the telnet
session began on. For example, if the client came in at port 23, I'd want
to set the environment variable "ABC" to "port23" (ie, ABC="port23";export
ABC). I'd want to give "ABC" a value of "port7023" if the client came in
at port 7023.
My problem: I don't know how to get the port number from within
the shell (/bin/sh). Any suggestions?
TIA,
-Rick
Karel Adams
"Richard Karl Getchell" <rget...@gorf.gpcc.itd.umich.edu> schreef in
bericht news:OIC97.267$yY2....@news.itd.umich.edu...
Could you not have inetd invoke two different scripts?
Each of these would first set $ABC as appropriate, afterwards they would be
identical.
Don't understand why /etc/profile must set $ABC.
KA (hopes this helps)
John DuBois
Karel Adams <k_a...@glo.be> wrote:
>
>"Richard Karl Getchell" <rget...@gorf.gpcc.itd.umich.edu> schreef in
>bericht news:OIC97.267$yY2....@news.itd.umich.edu...
>> the shell (/bin/sh). Any suggestions?
>
>Could you not have inetd invoke two different scripts?
>Each of these would first set $ABC as appropriate, afterwards they would be
>identical.
>Don't understand why /etc/profile must set $ABC.
Not much in the telnetd environment makes it through to a login session.
Offhand, I can only think of TZ. I suppose in your telnetd script you could
subvert TZ with something like
TZ=7023
and then in /etc/profile:
PORT=$TZ
. /etc/TIMEZONE # to reset TZ
(and do something equivalent in the initialization files for other shells in
use, if any)
John
--
John DuBois spc...@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/
Robert Carnegie
Robert Carnegie chooses to introduce himself as the fool who rushes in
where angels fear to thread. And I'm not sure how telnetd can set a
"correct" non-default value of TZ anyway...? (Hypothetical question.)
Not sure if this is at all helpful, but one other datum that (perhaps)
gets through from telnetd is that the process _is_ telnetd.
The second telnetd that you run could be renamed or linked to /etc/td7023,
I presume. Whether this helps depends on whether the user's shell process
can execute "ps -f" to see details of the root process that started the
shell - on OpenServer, that's "login", right? - and then the process that
started _that_ one, usually "telnetd". However, you may have security set
so that users _can't_ "see" these processes which don't belong to them.
That's why I said "perhaps".
Alternatively: "who -x -m" gives me this session user's host address or
name, but not the local port. "netstat -f inet" gives me host and port
information for all sessions. _If_ you know that the _only_ telnet
connections from hosts on 7023-type connections are going to be the
7023-type connections (I guess that there's a firewall involved), _then_
I suppose this will do, more or less -
hostaddress=`who -x -m | (read yada yada yada date time host;echo $host)`
if netstat -f inet | grep ".7023 " | grep " $hostaddress." |
grep -v " $hostaddress.7023 " >/dev/null
then
# this is a host using local port 7023
fi
Using ksh I can do "who -x -m | read yada yada yada yada yada hostaddress",
but in /bin/sh variables don't survive beyond the pipeline...?
And I'm presuming that Joe user is allowed to run "netstat" at least...
If you have to cope with (near-) concurrent connections to port 23 and
to port 7023 from the same host, this algorithm won't work, because all
it tells you is that there is _a_ connection to port 7023 from the
host in question, and not that _this_ connection is to port 7023.
It only works if on your network, those two statements are equivalent.
On the other hand, if a firewall's involved then the host address itself
should tell you - if you know how to read it - whether the host is
beyond the firewall or not, assuming that that's essentially all that you
want to know. I previously suggested executing "who -x -m" with the
environment variable HOSTRESORDER set to disable name lookup beyond
/etc/hosts (which apparently can't be disabled), which would give
you a raw IP address which you could compare to local routing tables.
_If_ the firewall is on the local network and not one or more sub-nets
away, then it should be feasible (...) to tell whether the route to your
host (the telnet client) points to the firewall, or elsewhere.
Then there's the network-address-translation type of firewall (we've
got one) where all the clients that come in through it appear to be
originating at the firewall itself anyway. So the last term in
"who -x -m" will be the firewall's address. And if that's all that
you wanted to know......
Bela Lubkin
> ... I previously suggested executing "who -x -m" with the
> environment variable HOSTRESORDER set to disable name lookup beyond
> /etc/hosts (which apparently can't be disabled), which would give
> you a raw IP address which you could compare to local routing tables.
Won't work. `who -x` reads /etc/wtmpx and reports whatever it finds
there, without attempting any sort of name lookup. It reports host
names because the program that wrote the wtmpx record (rlogind, telnetd,
sshd) did a name lookup. You would have to disable DNS in telnetd to
get it to write dotted IP addresses into wtmpx, and that might have
other consequences.
On the original question, there are many tricky ways this sort of thing
could be done. John DuBois's suggestion of using $TZ would work. e.g.
two scripts:
# telnet port 23 script
TZ=PST8PDT
export TZ
exec /etc/telnetd "$@"
# telnet port 7023 script
TZ=QST8QDT
export TZ
exec /etc/telnetd "$@"
Then in /etc/profile, check for the "QST" timezone, set it back to what
it should be.
Many other ways. You could probably set a ulimit:
#!/bin/ksh
# telnet port 23 script
ulimit -H -f 4000023
exec /etc/telnetd "$@"
#!/bin/ksh
# telnet port 7023 script
ulimit -H -f 4007023
exec /etc/telnetd "$@"
[in /etc/profile]
port=`ulimit`
case $port in
4000023) # set up for port 23;;
4007023) # set up for port 23;;
*) # didn't come in via one of those scripts, probably local login;;
esac
Basically, anything that gets transmitted down from parent to child
could be used. But telnetd very deliberately clears the environment of
all but a few variables (such as $TZ), so the most naive attempts will
not work.
Another method would be to use `lsof`:
ftp://vic.cc.purdue.edu/pub/tools/lsof/
It includes scripts that do similar things.
>Bela<