From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.4.1)
Description of problem:
Under 2.6 kernel, this C function call:
shmget(1866194712, 209715200, IPC_CREAT|IPC_EXCL|IPC_NOWAIT|0600);
will fail with EPERM (errno=1) if run as a normal user, with ENOMEM
(errno=12) if run as root (but it fails even trying to allocate 8KB...).
Removing the IPC_NOWAIT flag, everything runs ok. Under 2.4 kernel
there are no problem with or without the IPC_NOWAIT flag.
Reading /usr/src/linux-2.6/ipc/shm.c I was not able to find even
something returning EPERM...
Also, I cannot remove the flag because the failing program is the
Oracle database (version 10g).
P.S.: I'm sorry, my english is alpha version.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a C program calling shmget with IPC_NOWAIT flag
2. compile it
3. run it
Actual Results: The program fail with EPERM
Expected Results: An allocated shared memory segment
do you have selinux or anything related installed ?
Mine is a standard fedora core 1 (updated) with development 2.6.1
kernel. Sorry, but how the security can affect the result only with
IPC_NOWAIT flag set?
Works by 2.6.3 253 with selinux permissive.
The problem still persist on standard Fedora Core 2 (kernel
2.6.6-1.435.2.1) with default selinux configuration (SELINUX=disabled)
and with selinux=0 on boot too.
Ok I can duplicate this with the 2.6.6 tree.
Large values as non root correctly get -EINVAL
Small values with IPC_NOWAIT return -EPERM
Without IPC_NOWAIT performs correctly.
Doesn't seem ot be an SELinux bug but a general 2.6 bug in our tree.
Reassigning to the kernel owner
The flag in question isn't IPC_NOWAIT (IPC_NOWAIT is not valid for
this call, but SHM_HUGETLB). Once you realise that it becomes obvious
its not actually a bug. Oracle requires hugetlbfs/permissions