This is a discussion on Re: Patch for openssh server - openssh ; 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 ...
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
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 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.
>> 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 zip.com.au)
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