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.

>> 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.

>> On a related note, your patch does not appear to account for traffic
>> sent and received from port forwards

> That, I'll look into. Thanks.
>> (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).

> In case the user forwards a port on, 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.

>> 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"

>>> + 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 :-)

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
openssh-unix-dev mailing list