Moving logwtmp

Moving logwtmp

[Michael St. Laurent]

Hi folks, 

I'm new to the ppp list but I've been a member of the poptop-server list for
some time.  Something recently came up on that list that should properly be
addressed over here.

The discussion was "How do I know who is connected."  A command has been
cobbled together that will parse the output of ps and then do a lookup on
the log files but it was also pointed out that a few lines of code would
make a wtmp entry and thus solve the problem.

After looking at the pppd code I found the lines in auth.c where this is
done but, aparently, only if one is using PAP authentication.  Since almost
everyone using PPTP also uses Chap, this code is never called and we see
nothing in the who list.

I'm thinking that this code should be moved out of the plogin routine and
put somewhere else instead.  Am I making sense?

-- 
Michael St. Laurent
Hartwell Corporation

Re: Moving logwtmp

[James Cameron]

I agree.

plogin() in auth.c calls logwtmp().  plogin() is only called if PAP
authentication is being done, and the secret is "@login", meaning that
the system's authentication is being used.  Or PAM.

plogin() is only called by upap_rauthreq() in upap.c.  It is PAP
specific, I don't think it could be called by CHAP; as CHAP uses a
different model.

But even so, I can see that a logwtmp() in the other authentication
paths would help with accounting, and "who".

-- 
James Cameron

Re: Moving logwtmp

[James Carlson]

James Cameron writes:
> plogin() in auth.c calls logwtmp().  plogin() is only called if PAP
> authentication is being done, and the secret is "@login", meaning that
> the system's authentication is being used.  Or PAM.

Right.  The implication is that the remote peer name is authenticated
as being a system user.

> But even so, I can see that a logwtmp() in the other authentication
> paths would help with accounting, and "who".

I'm not so sure that's right.  The problem is that if the peer name
isn't authenticated as a system user name, then it's essentially an
arbitrary (and PPP-local) identifier, and it really ought not appear
in wtmp.  It'd be essentially equivalent to recording wtmp entries for
users authenticated via Apache .htaccess.

I'd support that as a configuration option, though, with appropriate
warnings.  ("If you do this, then your wtmp file will contain
PPP-authenticated names that might not match real UIDs on your system,
and may confuse the heck out of management software.")

-- 
James Carlson                                  <carlson@workingcode.com>

Re: Moving logwtmp

[Milan P. Stanic]

On Tue, Mar 16, 2004 at 07:54:04AM -0500, James Carlson wrote:
> I'd support that as a configuration option, though, with appropriate
> warnings.  ("If you do this, then your wtmp file will contain
> PPP-authenticated names that might not match real UIDs on your system,
> and may confuse the heck out of management software.")

Maybe is beter to make that compile time option.

RE: Moving logwtmp

[Michael St. Laurent]

James Carlson <mailto:carlson@workingcode.com> wrote:
> James Cameron writes:
>> plogin() in auth.c calls logwtmp().  plogin() is only called if PAP
>> authentication is being done, and the secret is "@login", meaning
>> that the system's authentication is being used.  Or PAM.
> 
> Right.  The implication is that the remote peer name is authenticated
> as being a system user.
> 
>> But even so, I can see that a logwtmp() in the other authentication
>> paths would help with accounting, and "who".
> 
> I'm not so sure that's right.  The problem is that if the peer name
> isn't authenticated as a system user name, then it's essentially an
> arbitrary (and PPP-local) identifier, and it really ought not appear
> in wtmp.  It'd be essentially equivalent to recording wtmp entries for
> users authenticated via Apache .htaccess.
> 
> I'd support that as a configuration option, though, with appropriate
> warnings.  ("If you do this, then your wtmp file will contain
> PPP-authenticated names that might not match real UIDs on your system,
> and may confuse the heck out of management software.")

Sure, a configuration option to turn it on or off would be an excellent
idea.

Where should the new code be located?

If nobody more qualified than I is willing to do this one then I'll take a
crack at it.  However, it might be best if someone more familiar with the
ppp source code were to do the honors.

-- 
Michael St. Laurent
Hartwell Corporation

Re: Moving logwtmp

[James Carlson]

Milan P. Stanic writes:
> On Tue, Mar 16, 2004 at 07:54:04AM -0500, James Carlson wrote:
> > I'd support that as a configuration option, though, with appropriate
> > warnings.  ("If you do this, then your wtmp file will contain
> > PPP-authenticated names that might not match real UIDs on your system,
> > and may confuse the heck out of management software.")
> 
> Maybe is beter to make that compile time option.

Why?  In my opinion, compile time options should be reserved for
extreme cases where it just can't be compiled at all on certain
systems without the flag.

Mere changes in behavior should not require the application to be
recompiled from source, should they?

-- 
James Carlson                                  <carlson@workingcode.com>

Re: Moving logwtmp

[Milan P. Stanic]

On Tue, Mar 16, 2004 at 03:26:08PM -0500, James Carlson wrote:
> Milan P. Stanic writes:
> > On Tue, Mar 16, 2004 at 07:54:04AM -0500, James Carlson wrote:
> > > I'd support that as a configuration option, though, with appropriate
> > > warnings.  ("If you do this, then your wtmp file will contain
> > > PPP-authenticated names that might not match real UIDs on your system,
> > > and may confuse the heck out of management software.")
> > 
> > Maybe is beter to make that compile time option.
> 
> Why?  In my opinion, compile time options should be reserved for
> extreme cases where it just can't be compiled at all on certain
> systems without the flag.

It depends how much overhead, stability and size they bring to code.
 
> Mere changes in behavior should not require the application to be
> recompiled from source, should they?

Rarely used features are compile time options. For example pam. ipv6,
srp, cbcp are commented in the Makefile.

Re: Moving logwtmp

[Milan P. Stanic]

On Tue, Mar 16, 2004 at 09:00:01PM -0500, James Carlson wrote:
> Milan P. Stanic writes:
> > > Mere changes in behavior should not require the application to be
> > > recompiled from source, should they?
> > 
> > Rarely used features are compile time options. For example pam. ipv6,
> > srp, cbcp are commented in the Makefile.
> 
> Not all systems support PAM or IPv6, or have the installed libraries
> required for SRP.  Those have to be omitted on the systems that don't
> have the underlying support.
> 
> As for CBCP, I'm not sure I understand what the rationale would be.
> Sure, CBCP is nasty, brutish stuff, but ifdef doesn't seem like the
> right answer.

IMO, all extensions should be compile time options. PPP is used in
different systems from servers to embedded devices (pda's, appliances ...)
and should be small as possible. Byte saved here, byte saved there
and the sistem can fit to flash memories and such devices.
So, the rarely used features shouldn't be in the binary by default,
but this is only my opinion.

Distributors of big OS distributions will build it with all options
enabled, I'm, sure ;)

People who installs from source will know how to enable features
which they want to have.

Re: Moving logwtmp

[James Carlson]

Milan P. Stanic writes:
> IMO, all extensions should be compile time options. PPP is used in
> different systems from servers to embedded devices (pda's, appliances ...)
> and should be small as possible.

Sure.  But this particular implementation isn't really designed to do
that.

If you're arguing that it should be, then I'd probably agree with you.
It'd be a real pile of work to get it into shape so that it could
actually be used in embedded environments.  Glad to see you've
volunteered.  ;-}

Among the things to worry about:

	- lack of support for multiple contexts (relies on VM -- one
          process per PPP instance)

	- lack of SNMP and other administrative interfaces

	- dependence on a POSIX-like filesystem and kernel behavior
          (including subtle things such as controlling tty semantics)

	- wrappers for "standard" C libraries

	- code hasn't been thoroughly audited (as far as I know) to
          make sure there are no slow memory leaks

> Distributors of big OS distributions will build it with all options
> enabled, I'm, sure ;)

The current set of targets for which ppp-2.4 successfully builds and
installs doesn't include anything but those "big OS distributions."

That might well constitute a bug in its own right, though.

> People who installs from source will know how to enable features
> which they want to have.

Sure ... but since I've actually done this in the past (albeit using
2.3 as a base), I can attest to the fact that ifdefs around an
arbitrary handful of services (and ifdefs that are themselves rarely
if ever tested -- and thus often fail to produce a working object when
disabled) doesn't help a lot, and does obscure the code.

-- 
James Carlson                                  <carlson@workingcode.com>

Re: Moving logwtmp

[Milan P. Stanic]

On Fri, Mar 19, 2004 at 03:52:48PM -0500, James Carlson wrote:
> If you're arguing that it should be, then I'd probably agree with you.
> It'd be a real pile of work to get it into shape so that it could
> actually be used in embedded environments.  Glad to see you've
> volunteered.  ;-}

I'd like, but don't have time :-(

Best regards