On Tuesday 15 August 2006 16:08, Darren Tucker wrote:
> Christian Iversen wrote:
> > On Tuesday 15 August 2006 07:53, Darren Tucker wrote:
> >> I see no such option (I'm not sure another sshd_config option would help
> >> your cause, though). Did you attach the version of the patch that you
> >> intended to?

> >
> > We didn't actually write that functionality, in case the patch would be
> > rejected. I'll add it right away if you think there's some chance it
> > could be accepted?

>
> No, I don't think an option would make a positive difference and it
> could be easily added if needed. I was just pointing out that the patch
> was not as described and wondered if this was accidental.


Ok - well I meant to write a note that this functionality was indeed missing,
but it seems I forgot.

> [...]
>
> >> Users of proftpd, apache and postfix don't usually have the option to
> >> run other programs to generate their network traffic.

> >
> > I'm sorry, but I don't really understand what you are trying to point
> > out? I mean, I can see that the statement is true, but I don't see the
> > relevance. If the user uses, say, mutt to read his email, would you
> > actually rather have mutt do the traffic accounting?

>
> No, if I cared about per-user traffic volumes I'd prefer that the system
> account for everything rather than instrumenting a bunch of
> applications. Users with shell access have lots of other ways to
> generate network traffic.


That's true, but ssh is still the right option for us. For instance, how would
you log the username with iptables or ?

> >> (it'll count it as it arrives in the encrypted pipe, but not once it
> >> goes back out over the network).

> >
> > You mean in the case of remote port forwards?

>
> Remote or local (ie ssh -L/-R).


That was a bad explanation on my part. I meant forwarding to another machine.

> > In case the user forwards a port on 127.0.0.1, we don't want to count
> > traffic. Or at least, we want to count it seperately.

>
> What about the server's local net? This is a good example of why you
> might want your packet filter to do your user accounting.


Well, I'm hoping we can find a compromise we can all live with. For instance,
we could ignore the problem completely in the first version :-)

We have written a specialized shell that only accepts rsync connections, in
order to use as a backup service. I'd rather have a very simple patch that
doesn't count retransmitted traffic, than a complex one that does.

> >> These types don't exactly match (u_long is preferred).

> >
> > I'm sorry, what do you mean? Are you referring to the signedness issue
> > below?

>
> "ulong" != "u_long"


Got it

> >>> + logit("Accounting: Bytes in/out: %ld/%ld", bytes_in, bytes_out);
> >>
> >> bytes_in and bytes_out are unsigned but the format string is signed.

> >
> > Oops, my bad. Indeed, that would be a problem if the user transferred
> > more bytes than there are atoms in the universe ;-)

>
> Yeah, it's not something that people are likely hit in an enormous hurry
> :-)


Not really, no ;-)

--
Regards,
Christian Iversen
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/lis...enssh-unix-dev