Description of problem: When the uid of a Unix user is between 0x20000 and 0x3ffff (upper bound), the IP address determined by get_ip_addr method in UnixUser is out of range. For example, if uid = 0x20000 and gid = 1, the IP calculated by UnixUser.get_ip_addr is 128.0.0.1. Moreover, a simple fix could be to narrow down the range of a uid to 0-131071. Version-Release number of selected component (if applicable): master How reproducible: always Steps to Reproduce: 1. run the attached script, which is a copy of self.get_ip_addr in model/user_user.rb Actual results: uid: 501 gid: 1 IP address: 127.0.250.129 uid: 501 gid: 10 IP address: 127.0.250.138 uid: 262143 gid: 1 IP address: 128.255.255.129 uid: 131072 gid: 1 IP address: 128.0.0.1 uid: 131071 gid: 127 IP address: 127.255.255.255 uid: 0 gid: 1 IP address: 127.0.0.1 Expected results: The IP address should be between 127.255.255.255 and 127.0.0.1. Additional info:
Created attachment 700330 [details] Test for UnixUser.get_ip_addr
Zhe, First of all, good catch. I need to close this bug as NOTABUG, because: 1. The runtime library is not responsible for enforcing the UID boundaries, and the IP floor is immutable at the moment. The broker and district system is what ensures the UIDs fit the overall IP allocation rules, and the code in UnixUser is sort of a leftover "last-ditch" check at the moment. So it's not currently possible for a value >= 131072 being received by the method given today's broker/districts. 2. This particular code path is not yet used- It's in master, but is code put in place to support the upcoming refactored cartridge work. There's no way to reach the code in the current master codebase unless you're developing/debugging new cartridges as part of our current sprint development work. So, ultimately any checks we do in this method are effectively pointless, and it's likely by the time the code is used in master we'll have removed this boundary checking altogether (leaving the enforcement to the broker). In the future, we would need to make this algorithm configurable in terms of UID bounds and IP floor to support true gear UID/IP range configurability up and down the stack. Thanks again for the detailed check, it has brought to light some interesting points about how we need to introduce more flexibility at the runtime layer.