Patch for openssh server

Darren Tucker dtucker at zip.com.au
Wed Aug 16 00:08:51 EST 2006


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



More information about the openssh-unix-dev mailing list