Restricting access via mgetty/AutoPPP

We have a stable dial-in setup using recent mgetty and AutoPPP.  We wish to prevent users from connecting multiple times in parallel.  Any ideas?  (I really don't want to give up AutoPPP)
remsteveAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
smileConnect With a Mentor Commented:
OK - I give up on this one.  AutoPPP is an internal feature of mgetty, so it looks like I'll have to hack into mgetty (unless pppd offers any hooks?).

Thanks for the thoughts

0
 
ahoffmannCommented:
In /etc/csh.login (/etc/.profile or whatever your user's login shell is) check if allready logged in (with w, ps aux, or whatever) and if so, perform a logout.
0
 
remsteveAuthor Commented:
The whole point of AutoPPP is that a shell is not invoked, so this suggestion is not feasible.
0
Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

 
remsteveAuthor Commented:
Adjusted points to 210
0
 
ahoffmannCommented:
see /etc/mgetty+sendfax/login.config, you can use your own login program instead of the default /bin/login
0
 
remsteveAuthor Commented:
Some missunderstanding here:
  > .. No /bin/login or shell is invoked ..
  > .. except for this multiple login problem.

Are they logged in? Or is your pppd-mashine just a router/gateway
handling dial-in sessions, then you must patch mgetty for your desires (I think).
0
 
ahoffmannCommented:
Good point.  It all depends how you define 'logged-in' I suppose.  Entries are written to wtmp and utmp, but the connections are ppp routing only.
0
 
remsteveAuthor Commented:
How can say that /bin/login is *not* invoked?
mgetty definitely calls /bin/login (or what was defined as default at compile time) or the program specified in mgetty.conf.

So I suggest you need you private login. Rebuild it from the original login source.

Do you agree?
0
 
ahoffmannCommented:
if I get it right, mgetty directly calls AutoPPP w/out any
/bin/login processing.

If you have a separate account for each user, you have the
chance to direct mgetty to first call a test program (you'll
have to write it, but it is simple), which looks for a file
/var/spool/uucp/LCK..<username> (or any other distinguishable
name), which contains the pid of the process for that user.
If the process exists (/procs/<pid>/) and is AutoPPP
(/proc/<pid>/cmdline), the user is online and test program
will exit. Else you have to create the lockfile new with
the actual pid and then do an exec to AutoPPP
(see: man 2 execve). This will preserve your actual pid,
so the next login test from the same user will see
AutoPPP running at the pid, which is stated in the users
lockfile.

This function won't work if either AutoPPP works on a
single account and manages the users itself or AutoPPP
exits while the connection keeps established, so the
check cannot check the presence/absence of the users
connection.

You may realize the test tool as a C program or even as
a simple shell script. For security reasons I would prefer
a C binary.

hope, that helps you

0
 
remsteveAuthor Commented:
Hi remsteve, a little late, so you might not get this.  We had the same problem and after looking around for a bit, I ended up hacking _pppd_ itself.  In the pap authorization module (I believe) right before it assigns the IP I run a quick script that does an awk to see if anyone else is online, it also does some stuff like look for a static.username file with a static IP if the customer has one, etc.  

At anyrate, just thought I'd help confirm that it's a hack job required and that you should probably be looking in pppd rather than mgetty.
0
All Courses

From novice to tech pro — start learning today.