| Summary: | support process_extended_limits() only if HAVE_GETRLIMIT is set | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | balu <balu.gajjala> |
| Component: | sftp-server | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | CC: | balu.gajjala, djm |
| Priority: | P5 | ||
| Version: | 8.5p1 | ||
| Hardware: | Other | ||
| OS: | Windows 10 | ||
| Bug Depends on: | |||
| Bug Blocks: | 3270 | ||
|
Description
balu
2021-04-07 04:38:34 AEST
I have wrapped the getlimit() call in HAVE_GETRLIMIT in commit f283a6c2e, but I don't see any reason to skip offering limits extension - it does offer additional limits beyond the one based on getrlimit() Thanks for your reply. I saw your commit f283a6c2e. one comment, ifdef HAVE_GETRLIMIT should be moved before struct rlimit rlim; After this change, on the machines where the rlimit is not supported, the nfiles (max-open-handles) will be sent as 0. How will the sftp client behave when sftp-server sends nfiles as 0? limits.(In reply to balu from comment #2) > Thanks for your reply. > I saw your commit f283a6c2e. > > one comment, > ifdef HAVE_GETRLIMIT should be moved before struct rlimit rlim; done > After this change, on the machines where the rlimit is not > supported, the nfiles (max-open-handles) will be sent as 0. How will > the sftp client behave when sftp-server sends nfiles as 0? Per PROTOCOL: If the server doesn't enforce a specific limit, then the field may be set to 0. This implies the server relies on the OS to enforce limits (e.g. available memory or file handles), and such limits might be dynamic. The client SHOULD take care to not try to exceed reasonable limits. Thank you for fixing it in no time. closing resolved bugs as of 8.6p1 release closing resolved bugs as of 8.6p1 release |