resource library (getrlimit, setrlimit) interprets resource limits as signed integers instead of unsigned

[ArturBieniek4]

Bug report

Bug description:

• as per System Calls Manual (man 2 setrlimit), rlim_t is an unsigned integer type
• in Python, reading the default hard limit (resource.getrlimit(resource.RLIMIT_CPU)) will return -1
• executing this:

resource.setrlimit(resource.RLIMIT_CPU, (-2, -2))
os.system("ulimit -t")

returns 18446744073709551614

• executing ulimit -t 18446744073709551614, then in python3 resource.getrlimit(resource.RLIMIT_CPU), will return -2

This behaviour is very weird and will cause the following rather useful and common snippet to fail:

_, hardlimit = resource.getrlimit(resource.RLIMIT_CPU)
rlimit = (min(timelimit, hardlimit), hardlimit)
resource.setrlimit(resource.RLIMIT_CPU, rlimit)

There happens to exist the following workaround:

_, hardlimit = resource.getrlimit(resource.RLIMIT_CPU)
softlimit = ctypes.c_long(min(seconds, ctypes.c_ulong(hardlimit).value)).value
rlimit = (softlimit, hardlimit)
resource.setrlimit(resource.RLIMIT_CPU, rlimit)

but it just feels extremely hacky to do things like this and I believe a lot of programmers end in this trap.
Especially that when you handle the -1 case specially (as it is mentioned in man, that "RLIM_INFINITY typically is the same as -1"), it still fails with other negative values like -2.

CPython versions tested on:

3.15

Operating systems tested on:

Linux

Linked PRs

• gh-137044: Support large limit values in getrlimit() and setrlimit() #137338
• [3.14] gh-137044: Support large limit values in getrlimit() and setrlimit() (GH-137338) #137506
• [3.13] gh-137044: Support large limit values in getrlimit() and setrlimit() (GH-137338) #137507
• gh-137044: Make resource.RLIM_INFINITY always positive #137511
• gh-137044: Revert "gh-137044: Make resource.RLIM_INFINITY always positive (GH-137511)" #137938
• gh-137044: Fix test_resource on 32-bit Linux #137941
• gh-137044: To weaken the statement regarding the RLIM_INFINITY value #137954

[serhiy-storchaka]

This is one of the cases where the integer type is unsigned, but -1 is a special value. RLIM_INFINITY is defined as ((__rlim_t) -1). It is more convenient to get/set -1 on all platforms than 0xffffffff or 0xffffffffffffffff depending on platform.

There is no standard way to handle this. We have special converters for uid_t, gid_t and dev_t. It seems that it is also needed for rlim_t.

[serhiy-storchaka]

I assigned this to myself because it requires writing non-trivial bulky code, and I've already started.

[serhiy-storchaka]

User code can depends on the fact that RLIM_INFINITY is -1 (although this is not documented). But there are reasons to represent it a large positive value, larger than any finite limit. One of them shown in the original report, but there is also the glibc feature on 32-bit platforms: if a program tried to set a resource limit to a value larger than can be represented in a 32-bit unsigned long, then the glibc setrlimit() wrapper function silently converted the limit value to RLIM_INFINITY.

So, I am planning two changes:

1. Support large values and reject negative values (except RLIM_INFINITY). This can be considered as a bug fix and can be backported.
2. Make RLIM_INFINITY a positive integer. This can only go in 3.15.

[serhiy-storchaka]

On some platforms RLIM_INFINITY is not (rlim_t)-1, but (rlim_t)-3, 2**31-1 or 2**63-1. On FreeBSD rlim_t is signed.