This is a discussion on Re: Patch for openssh server within the OpenSSH Development forums, part of the Networking and Network Related category; Christian Iversen wrote: > On Tuesday 15 August 2006 07:53, Darren Tucker wrote: >> I see no such ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org http://lists.mindrot.org/mailman/lis...enssh-unix-dev |