在Python中运行ioctl会返回ENOTTY-设备不适合的ioctl

Question

Hey i am having an issue trying to call ioctl linux system call from python.

Running the following line in C application i manage to get the parent file descriptor of a given linux namespace file descriptor.

#define NS_GET_PARENT   _IO(NSIO, 0x2)
struct stat sb;
fd = open("/proc/1337/ns/user", O_RDONLY);
parent_fd = ioctl(fd, NS_GET_PARENT);

But running the same following script in python gives me "inappropriate ioctl for device"

 from fcntl import ioctl
 NS_GET_PARENT = (0x7b << (4*2)) | 2
 f = open('/proc/1337/ns/user')
 fd = ioctl(f.fileno(),NS_GET_PARENT)

By running strace on both scripts i see that both issue the same system calls

 open("/proc/1337/ns/user", O_RDONLY) = 3
 ioctl(3, _IOC(0, 0xb7, 0x02, 0x00), 0)

The difference is that the C code actually returns a file descriptor to the parent name space while the python code returns

-1 ENOTTY (Inappropriate ioctl for device)

The issue replicates on 2 different machines(Linux Kernel 4.13.0-37) and both scripts are running with the same user. Anyone knows what might lead to that issue?

Answer 1

Note: There's now a Python 3 library available which covers the Linux namespace ioctl's: PyPi: linuxns-rel , GitHub: thediveo/linuxns_rel .

This was a tough question. There are two (three) aspects to why your example didn't work, and it took me some time to figure them out and learn alot about Linux namespaces.

First, it's NSIO=0xb7 (and not NSIO=0x7b ) as in your Python example, the correct value for NS_GET_PARENT thus is (I missed that bug totally at first, and noticed only after I had a working PoC done from scratch, mimiking the Linux header file macro defines very closely):

NS_GET_PARENT = (0xb7 << (4*2)) | 2

Second, your information about the exception thrown by Python's ioctl() seems to have a second mistake, based on what I see in my own experiments with Python 3: an inappropriate ioctl is ENOTTY (25). The ENOTTY would fit in with the mistaken NSIO of 0x7b instead of 0xb7 . In fact, when I tried your example verbatim, I got an ENOTTY . At that point I didn't realize that this is the indication of an invalid request code.

With the correct NS_GET_PARENT request code, the error EPERM (1) would fit the situation where the Linux kernel doesn't allow you to see the parent namespace, due to rights restrictions (even if you are superuser, you might be only locally inside another user userspace, et cetera).

So, this corrected code works, subject to access restrictions throwing OSError EPERM s:

from fcntl import ioctl
NS_GET_PARENT = (0xb7 << (4*2)) | 2
with open('/proc/self/ns/user') as f:
    fd = ioctl(f.fileno(), NS_GET_PARENT)

Since you don't give details about your system's user namespaces setup, I suspect that you felt victim to the same trap I felt for too: asking a process in the "root" user namespace for its parent user workspace: that simply throws a misleading EPERM , but that's correct as to what ioctl_ns(2) has to say.

A good trick for verification that the above code works, is to first start Firefox, and then sudo lsns -t user . This will show a set of Firefox child processes that run in their own user, ipc, and network namespaces. Take the PID of one of these Firefox child processes, and run the above example with it: it should now succeed and if you fstat() the file descriptor returned, it should reference the root user namespace. Trying to get the parent for the root user namespace should again fail with EPERM .