Non-Root Users Cannot set "ulimit" ?

[Alzhy]

HP-UX 11.11

My maxdsiz is set to 2GB.
ulimit defaults for both root and non-root is 1GB

As root, I can set it to 2GB:

root#devux03 # ulimit -d 2097152

But as a non-root user, I cannot:

ab7493@devux03 > ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 376832
memory(kbytes) unlimited
coredump(blocks) 4194303
ab7493@devux03 > ulimit -d 2097152
ksh: ulimit: exceeds allowable limit


So what's wrong here? How do I set things up so non-root users can get their data segsize grow beyond the default of 1GB..?

[Dennis Handly · Accepted solution]

>My maxdsiz is set to 2GB. ulimit defaults for both root and non-root is 1GB

This may be a shell bug and is just displaying it incorrectly. Are you able to allocate more than 1 GB in a 64 bit application?
If you have a 32 bit application, you can't allocate more than 1 GB unless you link with -N and/or use chatr(1) for +q3p & +q4p.

>How do I set things up so non-root users can get their data segsize grow beyond the default of 1GB?

Do you have proof that you are limited by 1 GB?
Also, do you have maxdsiz_64bit larger than maxdsiz?

Here are some links. In the first Bill has example programs for testing limits:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1125303
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1148462
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1211257

[Don Morris_1]

As Dennis points out, if ulimit is lower than maxdsiz - someone lowered it.

Presuming that ulimit is setting the "hard" resource limit (man setrlimit -- that's the underlying system call here), this is entirely normal and is due to the standard which defines this interface. Anyone may raise or lower soft limits within the boundary of their hard limit. Only privileged users (and root is pretty much always privileged for all these operations) can raise the hard limit.

I'd check for a profile which caused the limit to be lowered to 1Gb in the first place such that you have 2Gb hard limits (based on the tunable) and can then adjust soft limits if you care to. (According to a quick Google search this is usually a -S options (soft) instead of -H (hard). If neither is set, ulimit attempts to change both hard and soft -- and hence you're hitting the privilege issue of raising the hard limit).

That said - also as Dennis points out, a 2Gb limit is meaningless unless your binaries were compiled to use non-default address space layouts. You'll want to check that.

[Alzhy]

Thanks!

It turns out maxdsiz_64bit remained at 1GB whilst maxdsiz was increased to 2GB - and "ulimit/limit" sets the ceiling to the lower value declared between the 32 and 64 bit settings.

BUt what's puzzling is ROOT account can set a ulimit with these conditions in place whilst non-root user cannot.

[Don Morris_1]

No, that isn't puzzling. That's the standard.

First, assume we've got a 32-bit shell.

The original parent of all shells is the init process -- which is a 64-bit kernel process. Hence it is created with rlimits derived from maxdsiz_64bit (and maxssiz_64bit, etc.)

The shell is forked/exec'd. So we have a 32-bit child of a 64-bit parent. In that case, if the parent did not modify their limits we use the smaller of the parent or the 32-bit derived limits [because the standard dictates that children inherit limits from their parents, but you can't be allowed to bypass the 32-bit global limits form the tunables]. Hence the shell gets hard/soft limits from maxdsiz_64bit instead of maxdsiz here.

Now a user goes to use ulimit with no flags - as stated, that's raising both soft and hard limits. Because this is a 32-bit process, any hard limit increase up to maxdsiz is legal -- but only a privileged user may raise their hard limit. Hence, root (or superuser equivalent) will succeed in the ulimit, non-superuser will not.

[Alzhy]

Indeed your explanation is correct.

I sure hope the kernel rebuild process features logical checks so this sitaution can be avoided.

Thanks!

[Dennis Handly]

>I sure hope the kernel rebuild process features logical checks so this situation can be avoided.

Obviously it doesn't. And on 11.23, this is a dynamic tunable.

If you want to prevent this mistake in the future, please file an enhancement request to the Response Center.