Bug 913353

Summary: Internal IP address of UnixUser out of range
Product: OKD Reporter: Zhe Wang <zhewang>
Component: ContainersAssignee: Dan Mace <dmace>
Status: CLOSED NOTABUG QA Contact: libra bugs <libra-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.xCC: dmace, xtian
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-22 18:50:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test for UnixUser.get_ip_addr none

Description Zhe Wang 2013-02-21 03:35:45 UTC 
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:
Comment 1 Zhe Wang 2013-02-21 03:36:27 UTC 
Created attachment 700330 [details]
Test for UnixUser.get_ip_addr
Comment 2 Dan Mace 2013-02-22 18:50:05 UTC 
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.