XenevaOS
Loading...
Searching...
No Matches
capability.h
Go to the documentation of this file.
1#ifndef __LINUX_CAPABILITY_H__
2#define __LINUX_CAPABILITY_H__
3
4/* bool -- checkpoint_restore_ns_capable() returns one. This header had no
5 * includes at all, so the type came from nowhere. */
6#include <stdbool.h>
7
8/*
9 * DCL <linux/capability.h> -- Xeneva does not model Linux capabilities yet.
10 * capable() answers yes so mainline driver entry points that gate themselves
11 * (open_port() on /dev/mem is the mem.c case) stay reachable; the devfs node
12 * permissions remain the real access gate, as they are for every other
13 * Xeneva device node.
14 */
15
16#define CAP_SYS_RAWIO 17
17
18static inline int capable(int cap) {
19 (void)cap;
20 return 1;
21}
22
23
24/*
25 * CAP_SYS_ADMIN -- the capability three of serial_core.c's gates name:
26 * uart_set_options() (:349), uart_get_lsr_info() (:1136) and the
27 * TIOCSSERIAL path (:938). Numbered 21 because that is mainline's value in
28 * include/linux/capability.h and a capability number is an ABI constant if
29 * anything ever reads it back from userspace.
30 *
31 * capable() ignores its argument and answers yes (see its own comment at the
32 * top of this file), so the *number* only ever reaches `(void)cap` -- it is
33 * defined for the same reason the named error codes are: the source spells
34 * it, and an undefined identifier there would otherwise be read as 0 by
35 * IS_ENABLED-style macros or fail outright as an enum member.
36 */
37#define CAP_SYS_ADMIN 21
38
39/*
40 * CAP_SYS_MODULE 16 -- tty_ldisc.c:153, the gate in front of
41 * request_module("tty-ldisc-%d"): `!capable(CAP_SYS_MODULE) &&
42 * !tty_ldisc_autoload`. 16 is mainline's number in
43 * include/linux/capability.h, for the reason CAP_SYS_ADMIN's comment gives:
44 * it may never be compared with anything, but it is spelled as a decimal
45 * literal and an undefined identifier there would be read as 0 -- which here
46 * would mean CAP_CHOWN rather than an unknown capability.
47 *
48 * capable() ignores its argument (top of this file), so the branch resolves to
49 * `0 && !tty_ldisc_autoload` and the -EPERM arm is skipped unconditionally.
50 */
51#define CAP_SYS_MODULE 16
52
53/*
54 * struct user_namespace / init_user_ns -- and checkpoint_restore_ns_capable(),
55 * called once, at tty_ioctl.c:843, to gate TIOCSLCKTRMIOS (locking the line
56 * settings of a terminal) behind a capability check.
57 *
58 * mainline keeps the type and the object in <linux/user_namespace.h> and the
59 * predicate in <linux/capability.h> here; DCL has no user_namespace.h, and
60 * the predicate is the only thing that needs either, so both live beside it.
61 * The struct is a placeholder member and nothing more: the object exists so
62 * that `&init_user_ns` has an address to take, and it is never dereferenced
63 * -- mainline's is roughly sixty fields of uid/gid mapping, all of which
64 * answer a question this build has no way to ask.
65 *
66 * The predicate answers yes for the same reason capable() does: DCL's access
67 * gate is the devfs node's permissions, not the capability bitmap. mainline's
68 * body is `ns_capable(ns, CAP_CHECKPOINT_RESTORE) || ns_capable(ns,
69 * CAP_SYS_ADMIN)`; there is no ns_capable() here to call and no namespace
70 * table to look the caller up in, so the argument is dropped rather than
71 * consulted -- which is why the struct can be this empty.
72 *
73 * upstream include/linux/user_namespace.h (type + object),
74 * include/linux/capability.h:200 (the predicate)
75 */
78};
79
80extern struct user_namespace init_user_ns;
81
82static inline bool checkpoint_restore_ns_capable(struct user_namespace* ns)
83{
84 (void)ns;
85 return true;
86}
87
88#endif /* __LINUX_CAPABILITY_H__ */
struct user_namespace init_user_ns
Definition capability.h:76
void * placeholder
Definition capability.h:77