[survey] Do you use auth/identd?
Brooke Paul
upon the RFC 931 auth/identd protocol. I was wondering if other
MUDs have set up such authorization.
Basically, it allows us to reject login from specific
users and to significantly decrease double logging. I would be
interested to see if other admins have set up such measures, and
how they did it.
Alex Greenbank
: I have recently implemented player authorization based
I am implementing it on my mud (Aber). Basically it will log the RFC 931
info when the person connects. It won't check for double char'ing etc.
But I'll be able to sift through the logs and spot the ppl doing it.
Its a simple thing to implement, within the user entry you need to record
the port which is attainable from the struct used in accept I think...
-Alex (Snell)
Paul Wouters
> I have recently implemented player authorization based
>upon the RFC 931 auth/identd protocol. I was wondering if other
>MUDs have set up such authorization.
> Basically, it allows us to reject login from specific
>users and to significantly decrease double logging. I would be
>interested to see if other admins have set up such measures, and
>how they did it.
the Tmi-2 mudlib comes with an auth daemon written by Robocoder. It has
been disabeled from use though, because if would have cut off too many
people.
Paul
--
Say a prayer for me, help me to feel the strength I did
My identity, has it been taken, is my heart breaking on me
All my plans, they fell through my hands, they fell through my hands
All my dreams, it suddenly seems.....Empty - The Cranberries
Justin B. Harvey
> I have recently implemented player authorization based
>upon the RFC 931 auth/identd protocol. I was wondering if other
>MUDs have set up such authorization.
> Basically, it allows us to reject login from specific
>users and to significantly decrease double logging. I would be
>interested to see if other admins have set up such measures, and
>how they did it.
I run TexasTwilight MUSH which is a 2.0.10pl6 version of TinyMUSH and am also
working on a 2.2.1 version. I have identd code working on the former but
haven't ported it to the second. I use identd only for identification
purposes, not denial of service.
The patches for MUSH are:
ftp.cis.upenn.edu:/pub/lwl/src/misc/ident*
Justin
Aladdin
John W. Schwegler
: I have recently implemented player authorization based
: upon the RFC 931 auth/identd protocol. I was wondering if other
: MUDs have set up such authorization.
: Basically, it allows us to reject login from specific
: users and to significantly decrease double logging. I would be
: interested to see if other admins have set up such measures, and
: how they did it.
We use the protocol on Kaos Headquarters. An asynchronous daemon runs
alongside the main mud, and returns information as it becomes available.
Players connected to the game may actually be rejected after they've been
able to log in, if inquiry time exceeds a set timeout value. We do this
for the convenience of the majority of our players, in case queries take
a long time to be answered.
We use regular expressions to reject/allow/prevent new characters by
combinations of site name, remote user name, and character name. We also
notify immortals of multiple logins from a single account, but do not
currently dump them out automatically.
-john aka Loric of Kaos HQ (flower.aud.temple.edu 4000)
--
______________________________________________________________________________
"Genius may have its limitations, | John Schwegler
but stupidity is not thus | Temple U. Auditory Research Dept.
handicapped." | jo...@flower.aud.temple.edu
- Elbert Hubbard | (215) 707-3687 FAX 707-3650
Schultz, Russell
>In article <40880s$3...@cronkite.ocis.temple.edu>,
>John W. Schwegler <jo...@flower.aud.temple.edu> wrote:
>>
>>We use the protocol on Kaos Headquarters. An asynchronous daemon runs
>>alongside the main mud, and returns information as it becomes available.
>>Players connected to the game may actually be rejected after they've been
>>able to log in, if inquiry time exceeds a set timeout value. We do this
>>for the convenience of the majority of our players, in case queries take
>>a long time to be answered.
>>
>
>
>Why should it matter if it takes a long time to be answered.. I mean, sure you
>can stop the whole mud until it gets back, but that's kinda dumb IMHO.
> I wrote my own server (tested it a few times and what not, but it's not
>in use very much, so I don't know any problems that might arise) that
>uses the ident protocol. I just treats the connection like you would a
>players connection (if there's nothing on the socket, ignore it for now, and
>go onto the next one). I've had no problems using it, nor has it lagged the
>server waiting for the info (and everyone else connected goes on freely).
> If there is a problem that I'm not seeing (I'm not the best networking
>programmer... actually, I'm pretty clueless) then could someone explain
>it to me?
>
Any calls in the gethostXXXX() family dont have setable timeouts...if you've a lousy name server, it can take up to 5 minutes to fi=
nally say "nope, cant find it".
When you're doing that....it blocks, and the server quits for that period of time....and its just plain old no good.
We use an asyncronous ident/name resolver also, just for the same reason.
Russ/Poo...@ronin.bchs.uh.edu 5000
Josh Rantane
John W. Schwegler <jo...@flower.aud.temple.edu> wrote:
>
>We use the protocol on Kaos Headquarters. An asynchronous daemon runs
>alongside the main mud, and returns information as it becomes available.
>Players connected to the game may actually be rejected after they've been
>able to log in, if inquiry time exceeds a set timeout value. We do this
>for the convenience of the majority of our players, in case queries take
>a long time to be answered.
>
Why do you use a differnt server? Why not just use the main muds server?
Why should it matter if it takes a long time to be answered.. I mean, sure you
can stop the whole mud until it gets back, but that's kinda dumb IMHO.
I wrote my own server (tested it a few times and what not, but it's not
in use very much, so I don't know any problems that might arise) that
uses the ident protocol. I just treats the connection like you would a
players connection (if there's nothing on the socket, ignore it for now, and
go onto the next one). I've had no problems using it, nor has it lagged the
server waiting for the info (and everyone else connected goes on freely).
If there is a problem that I'm not seeing (I'm not the best networking
programmer... actually, I'm pretty clueless) then could someone explain
it to me?
Thanks,
Josh
--
http://voyager.cns.ohiou.edu/~jrantane - The Jesus Connection
jran...@oucsace.cs.ohiou.edu
Bob Farmer
>nally say "nope, cant find it".
>
>When you're doing that....it blocks, and the server quits for that period of time....and its just plain old no good.
>
>We use an asyncronous ident/name resolver also, just for the same reason.
Fortunately, since the player is connected we can get address numbers...
There is no need to use any gethost*() functions. Now, again, why do we
need a separate process for ident? (And, yes, I understand needing a
separate process for name resolving.)
--
Bob Farmer ucs...@pip.shsu.edu
University Computer Services, Sam Houston State Univ. (409)294-3546
Anthony Pang
Schultz, Russell <schultz...@semail.jsc.nasa.gov> wrote:
>jran...@voyager.cns.ohiou.edu (Josh Rantane) wrote:
>>In article <40880s$3...@cronkite.ocis.temple.edu>,
>>John W. Schwegler <jo...@flower.aud.temple.edu> wrote:
>>>
>>>We use the protocol on Kaos Headquarters. An asynchronous daemon runs
>>>alongside the main mud, and returns information as it becomes available.
>>
>>Why should it matter if it takes a long time to be answered.. I mean, sure
>>you can stop the whole mud until it gets back, but that's kinda dumb IMHO.
>
>"nope, cant find it".
How one implements this depends on the whims of the programmer to code
it--whether in the driver or mudlib or externally.
However, I will add this:
If you have an open connection already, you don't need to use gethostbyX().
You can query the ip from the socket's sockaddr_in structure, which you
got from accept().
To open a connection to the remote site's identd port, you only need the
ip number. Converting it to a host name is a waste of CPU.
Also, it appears from the above, that some people haven't learned how
to set a socket to non-blocking. Why use an asychronous process, when
you can set the socket asynchronous?
Asko Seeba
: I have recently implemented player authorization based
: upon the RFC 931 auth/identd protocol. I was wondering if other
: MUDs have set up such authorization.
: Basically, it allows us to reject login from specific
: users and to significantly decrease double logging. I would be
: interested to see if other admins have set up such measures, and
: how they did it.
I'm implementing on Stonia. We don't use this ability yet 'cause Stonia has
still DIKU based code and we are afraid of that how lazy might become... But we
develop new code in threaded and objectoriented style and suppose that it is
good idea to include that feature. But one suggestion I can give... If you
don't want to scratch that function from the very beginning, you can use as
well the part of sendmail program, which deals exactly with that... but... try
to get latest version 'cause it is said that before there was a bug (exactly in
that function) and now it is fixed.
--
Asko Seeba.
Schultz, Russell
Maybe you dont know as much as you think? *chuckle*
gethost*****() just BLOCKS. PERIOD. It doesnt matter if every socket in your program is set to non-blocking. BLOCK BLOCK BLOCK.
True, its not _required_ that you get the host name, but I personally recognize my players easier by site names than by numbers.
And, if you want to talk about a waste of CPU time, its getting information from the identd process--most systems DONT run it, and its easily spoofable.
Russ/Poo...@ronin.bchs.uh.edu 5000
Joern Rennecke
>Fortunately, since the player is connected we can get address numbers...
>There is no need to use any gethost*() functions. Now, again, why do we
connect() blocks. Depending on link to the destination address, this can be
quite annoying.
>need a separate process for ident? (And, yes, I understand needing a
>separate process for name resolving.)
Well, one advantage is that it saves descriptors for the mud proceess.
Albeit it is in principle possible to process an FD_SET pretty fast,
I have yet to see a select() implementation that actually does.
Linux has quite a lot of overhead to generate EBADF. SunOS <= 4.x does not
qualify for large muds at all: the descriptor limit of 128 is lower that
what you often see as number of logged in players.
Another advantage to use a separate process is modularity. If an alternate
protocol to inetd comes up that allows to query from a third host and/or
that implements authorisation forwarding for people that do a remote login
and/or uses some fancy security system that requires special privileges under
unix, this can be neatly encapsulated.
Moreover, allowing outbound tcp/ip connections from the mud is a security
issue. LPC coded security cannot replace external security, because it is
well-known that MUDs are more complex, faster changing and their maitenance
less strictly controlled than operating systems or host configurations.
Therefore, you would have to hard-code every feature associated with outbound
TCP/IP connections into the driver along with the assoicated security checks.
This is bad because of
- ad-hoc driver changes
- driver bloat
- you have to reboot the MUD whenever something in these functionality has
to change
- it is very hard to ascertain correctness of an entire mud driver,
while on the other hand the external processes can be pretty small and thus
be verified easier.
- Using a separate process allows to exploit paralellism. The page table for
a mud can grow quite large, thus frequent forking in mid-operations should
be avoided if possible.
A possible denial-of-service attack against a mud that has inetd
authorisation in the driver is actually to spew a large number of incoming
connections at it.
Amylaar
Petri Virkkula
Amylaar> Linux has quite a lot of overhead to generate EBADF. SunOS <=
Amylaar> 4.x does not qualify for large muds at all: the descriptor
Amylaar> limit of 128 is lower that what you often see as number of
Amylaar> logged in players.
I believe that SunOS 4.1.3 has max descriptor limit 256, but
stdio library uses signed char as filehandle which limits
filehandles to 128 but the stdio part of libc can be replaced
for example from GNU libc.
Petri
--
--------------------------------------------------------------------------
Petri Virkkula | Internet: Petri.V...@hut.fi
JMT 11 E 125 | X.400 : /G=Petri/S=Virkkula/O=hut/ADMD=fumail/C=fi/
02150 Espoo | Tel home: +358 0 455 1277
FINLAND | Tel work: +358 0 8941 4540
--------------------------------------------------------------------------
Zump
--
Will hack Perl, HTML and CGI for toys. | http://rom.efn.org
Boycott Intel! | telnet://rom.efn.org:9000
Stuart Yeates
: - Using a separate process allows to exploit paralellism. The page table for
: a mud can grow quite large, thus frequent forking in mid-operations should
: be avoided if possible.
If I understand UNIX virtual memory correctly, a fork() followed by
an exec() in the child process should not result in duplication of
the full address space. As soon as the exec() is called, the entire
address space (other than argc, argv[], envc and envv[]) are thrown
away. The problem arises when you have a process which fork()s and
doesn't exec() in one of the children, in this case, the entire
address space is duplicated. But for this to occur, implies that you
would have two muds, each containing identical rooms, mobs and
players running on the same machine...
Colin Coghill
: : a mud can grow quite large, thus frequent forking in mid-operations should
: : be avoided if possible.
:
: If I understand UNIX virtual memory correctly, a fork() followed by
: an exec() in the child process should not result in duplication of
: the full address space. As soon as the exec() is called, the entire
Mmm, I don't think the actual address space gets duplicated until it's
used, but the page tables probably would. (The structure the OS uses
to keep track of how memory is being allocated for the process).
And yes, MUD's would (I think) tend to grow large page tables over time.
- Colin
--
co...@utf.gen.nz |
co...@kcbbs.gen.nz | This space for rent
co...@inzo.co.nz |
-------------------------+---+---------------------------------------
Campaigning for 4 line sigs | BAAWA, Junior Lt, 3rd Assault Div.
Joern Rennecke
>Joern Rennecke (amy...@meolyon.hanse.de) wrote:
>: - Using a separate process allows to exploit paralellism. The page table for
>: a mud can grow quite large, thus frequent forking in mid-operations should
>: be avoided if possible.
>If I understand UNIX virtual memory correctly, a fork() followed by
>an exec() in the child process should not result in duplication of
>the full address space. As soon as the exec() is called, the entire
Would you like to share with us how you hack the kernel so that fork need
less than copying the PAGE TABLES and mark both the original and the copy as
copy-on-write?
Amylaar
Alexander Weidt
>stu...@csc.canterbury.ac.nz (Stuart Yeates) writes:
>>Joern Rennecke (amy...@meolyon.hanse.de) wrote:
well, you can always vfork()... then again not even in computer science can you
get a free lunch..
> Amylaar
happy hacking, alex.
Stephen F. White
Joern Rennecke <amy...@meolyon.hanse.de> wrote:
> connect() blocks. Depending on link to the destination address, this can be
> quite annoying.
why don't you set the socket non-blocking?
[understandable performance reasons deleted]
i understand the need for asynchronous name lookups.
believe it or not, this is one thing that winsock got right:
there is a WSAAsyncGetHostByName().
-=- sfw
--
stephen f. white
s...@io.org
http://csclub.uwaterloo.ca/u/sfwhite
"language is a virus from outer space" -- w.s.b.
Joern Rennecke
>In article <1995Aug12....@meolyon.hanse.de>,
>Joern Rennecke <amy...@meolyon.hanse.de> wrote:
>> connect() blocks. Depending on link to the destination address, this can be
>> quite annoying.
>why don't you set the socket non-blocking?
From the connect(2) man page:
RETURN VALUE
If the connection or binding succeeds, zero is returned.
On error, -1 is returned, and errno is set appropriately.
You see, the semantics of connect(2) don't allow non-blocking operation for
SOCK_STREAM sockets.
Amylaar
Steven Singer
From later in the connect(2) manual page on SunOS 4.1.3 :
EINPROGRESS The socket is non-blocking and the con-
nection cannot be completed immediately.
It is possible to select(2) for comple-
tion by selecting the socket for writ-
ing.
However, as others have correctly pointed out, although the connection
to authd can be made non-blocking and all the authentication done
without forking, the system call gethostbyaddr, over which you have no
control, uses blocking sockets to connect to the DNS.
I guess you could write your own DNS query routines which used
non-blocking sockets. The information sould be in an RFC somewhere.
Skipping gethostbyaddr and going to the resolver(3) interface doesn't
look like it will gain you anything as there is no provision there for
non-blocking queries.
All in all, I suspect, it's easier to just fork and let the child block
on gethostbyaddr. The child may as well perform the authd lookup and
return all the information back to the parent along a single file
descriptor.
- Steven
Stephen F. White
Joern Rennecke <amy...@meolyon.hanse.de> wrote:
> s...@io.org (Stephen F. White) writes:
>> why don't you set the socket non-blocking?
> From the connect(2) man page:
> RETURN VALUE
> If the connection or binding succeeds, zero is returned.
> On error, -1 is returned, and errno is set appropriately.
> You see, the semantics of connect(2) don't allow non-blocking operation for
> SOCK_STREAM sockets.
-1 is returned, and errno is set to EWOULDBLOCK. handling it in the
select() is a bit weird. you mark it in the output fd's, and it
marks itself ready for writing when it actually connects.
have you ever used tinyfugue? it uses non-blocking connect all the time.
Marcus Meissner
Joern Rennecke <amy...@meolyon.hanse.de> wrote:
>s...@io.org (Stephen F. White) writes:
>
>>Joern Rennecke <amy...@meolyon.hanse.de> wrote:
>
>>> connect() blocks. Depending on link to the destination address, this can be
>>> quite annoying.
>
>
>From the connect(2) man page:
>
>RETURN VALUE
> If the connection or binding succeeds, zero is returned.
> On error, -1 is returned, and errno is set appropriately.
>
>You see, the semantics of connect(2) don't allow non-blocking operation for
>SOCK_STREAM sockets.
I think this is implementation dependend.
SunOS (4.1.3 AND 5.4),HPUX 9 allow non-blocking connects. Linux doesn't
(I have checked the source for Linux, the manpages for the other OS'es)
> Amylaar
Marcus
Andrew Molitor
|>
|> I think this is implementation dependend.
|> SunOS (4.1.3 AND 5.4),HPUX 9 allow non-blocking connects. Linux doesn't
|> (I have checked the source for Linux, the manpages for the other OS'es)
Most or all allow non-blocking connects. Anything BSD derived, and
that's everything except Linux, despite the loud claims of total rewrites.
Set the socket non-blocking, do the connect(). If it succeeds, great. If it
fails, check errno, if it's anything other than EWOULDBLOCK (or local
equivalent), you're dead, kill it. If it's would block, remember to select
that fd for reading and for writing next time you select(). When the select
comes back, if the socket is select()'d for writing, the operation is
complete. If it's selected for reading, as well, the operation has failed.
(I might have reading/writing backwards, but I think that's right).
This is not 100% portable, but it's pretty much the the closest thing
to portable there is. You can also do stuff like ignore SIGPIPE and attempt
to write on the socket, when the select returns, that sort of thing. The
real trouble is that errno is useless to you, since the select() will
overwrite it, probably with 'ESUCCESS' or something when it returns, so
there's no channel for the outstanding connect() to signal success.
Andrew
|> Marcus