p9auth: split core function out of some set*{u,g}id functions

This is a driver that adds Plan 9 style capability device implementation. See Documentation/p9auth.txt for a description of how to use this.

 Documentation/p9auth.txt     |   47 ++++
 drivers/char/Kconfig         |    2 +
 drivers/char/Makefile        |    2 +
 drivers/char/p9auth/Kconfig  |    9 +
 drivers/char/p9auth/Makefile |    1 +
 drivers/char/p9auth/p9auth.c |  517 ++++++++++++++++++++++++++++++++++++++++++

 6 files changed, 578 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/p9auth.txt
 create mode 100644 drivers/char/p9auth/Kconfig
 create mode 100644 drivers/char/p9auth/Makefile
 create mode 100644 drivers/char/p9auth/p9auth.c

Documentation/p9auth.txt new file +13 -0

new file mode 100644
index 0000000..14a69d8
@@ -0,0 +1,47 @@
+The p9auth device driver implements a plan-9 factotum-like
+capability API.  Tasks which are privileged (authorized by
+possession of the CAP_GRANT_ID privilege (POSIX capability))
+can write new capabilities to /dev/caphash.  The kernel then
+stores these until a task uses them by writing to the
+/dev/capuse device.  Each capability represents the ability
+for a task running as userid X to switch to userid Y and
+some set of groups.  Each capability may be used only once,
+and unused capabilities are cleared after two minutes.
+
+The following examples shows how to use the API.  Shell 1
+contains a privileged root shell.  Shell 2 contains an
+unprivileged shell as user 501 in the same user namespace.  If

Granting userid capabilities to another task is a dangerous privilege. Don't just let file permissions authorize it. Define CAP_GRANT_ID as a new capability needed to write to /dev/caphash.

Quoted 3 lines · Serge E. Hallyn

This is a driver that adds Plan 9 style capability device implementation. See Documentation/p9auth.txt for a description of how to use this.

Hm, you didn't originally write this driver, so it would be good to get some original authorship information in here to keep everything correct, right?

Quoted 6 lines

 Documentation/p9auth.txt     |   47 ++++
 drivers/char/Kconfig         |    2 +
 drivers/char/Makefile        |    2 +
 drivers/char/p9auth/Kconfig  |    9 +
 drivers/char/p9auth/Makefile |    1 +
 drivers/char/p9auth/p9auth.c |  517 ++++++++++++++++++++++++++++++++++++++++++

Is this code really ready for drivers/char/? What has changed in it that makes it ok to move out of the staging tree?

And who is going to maintain it? You? Or someone else?

Quoted 30 lines

 6 files changed, 578 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/p9auth.txt
 create mode 100644 drivers/char/p9auth/Kconfig
 create mode 100644 drivers/char/p9auth/Makefile
 create mode 100644 drivers/char/p9auth/p9auth.c

Documentation/p9auth.txt new file +18 -0

new file mode 100644
index 0000000..14a69d8
@@ -0,0 +1,47 @@
+The p9auth device driver implements a plan-9 factotum-like
+capability API.  Tasks which are privileged (authorized by
+possession of the CAP_GRANT_ID privilege (POSIX capability))
+can write new capabilities to /dev/caphash.  The kernel then
+stores these until a task uses them by writing to the
+/dev/capuse device.  Each capability represents the ability
+for a task running as userid X to switch to userid Y and
+some set of groups.  Each capability may be used only once,
+and unused capabilities are cleared after two minutes.
+
+The following examples shows how to use the API.  Shell 1
+contains a privileged root shell.  Shell 2 contains an
+unprivileged shell as user 501 in the same user namespace.  If
+not already done, the privileged shell should create the p9auth
+devices:
+
+	majfile=/sys/module/p9auth/parameters/cap_major
+	minfile=/sys/module/p9auth/parameters/cap_minor

Documentation/p9auth.txt line 23

Quoted 5 lines

Documentation/p9auth.txt new file +5 -0

+	maj=`cat $majfile`
+	mknod /dev/caphash c $maj 0
+	min=`cat $minfile`
+	mknod /dev/capuse c $maj 1
+	chmod ugo+w /dev/capuse

That is incorrect, you don't need the cap_major/minor files at all, the device node should be automatically created for you, right?

And do you really want to do all of this control through a device node? Why?

Documentation/p9auth.txt line 24

Quoted 1 line

Documentation/p9auth.txt new file +1 -0

+DEFINE_MUTEX(cap_mutex); /* TODO fix up the locking one day */

One might hope that today would be that day...

Also, please run this through sparse. This is a variable that doesn't need to be global.

Documentation/p9auth.txt line 27

Quoted 3 lines

Documentation/p9auth.txt new file +3 -0

+struct cap_dev {
+	struct cdev cdev;
+};

Do you really need to do it this way? A cdev for a single device node? That's major overkill.

Documentation/p9auth.txt line 29

Quoted 2 lines

Documentation/p9auth.txt new file +2 -0

+static int cap_major = CAP_MAJOR;
+static int cap_minor;

Just always use a dynamic misc device, you never need a whole major for this.

Documentation/p9auth.txt line 31

Quoted 2 lines

Documentation/p9auth.txt new file +2 -0

+module_param(cap_major, int, S_IRUGO);
+module_param(cap_minor, int, S_IRUGO);

Can be removed.

Documentation/p9auth.txt line 32

Quoted 1 line

Documentation/p9auth.txt new file +1 -0

+MODULE_AUTHOR("Ashwin Ganti");

Hm, who is going to maintain this, you, or Ashwin?

Documentation/p9auth.txt line 38

Quoted 6 lines

Documentation/p9auth.txt new file +6 -0

+static void hexdump(unsigned char *buf, unsigned int len)
+{
+	while (len--)
+		printk(KERN_DEBUG "%02x", *buf++);
+	printk(KERN_DEBUG "\n");
+}

We have a built-in function for this already.

Oh, this function is also incorrect, which is a good reason to use the built-in ones.

I'm going to stop now, this doesn't belong in drivers/char/ yet, it needs work...

thanks,

greg k-h

Documentation/p9auth.txt line 44

Quoted 6 lines

Documentation/p9auth.txt new file +6 -0

+/*
+ * read an entry.  For now it is
+ * source_user@target_user@rand
+ * Next it will become
+ * source_user@target_user@target_group@numgroups@grp1..@grpn@rand
+ */

Hm, wait, one more.... The kernel/user api is going to change some time in the future? Please fix this now before it gets merged.

Quoted 1 line · Greg KH

Hm, who is going to maintain this, you, or Ashwin?

I haven't asked Ashwin, and will be happy either way.  Ashwin, did you want to maintain it?

Quoted 8 lines · Greg KH

Quoted 3 lines · Serge E. Hallyn

This is a driver that adds Plan 9 style capability device implementation. See Documentation/p9auth.txt for a description of how to use this.

Hm, you didn't originally write this driver, so it would be good to get some original authorship information in here to keep everything correct, right?

That's why I left the MODULE_AUTHOR line in there - not sure what else to do for that. I'll add a comment in p9auth.txt, especially pointing back to Ashwin's original paper.

Quoted 9 lines

Quoted 6 lines

 Documentation/p9auth.txt     |   47 ++++
 drivers/char/Kconfig         |    2 +
 drivers/char/Makefile        |    2 +
 drivers/char/p9auth/Kconfig  |    9 +
 drivers/char/p9auth/Makefile |    1 +
 drivers/char/p9auth/p9auth.c |  517 ++++++++++++++++++++++++++++++++++++++++++

Is this code really ready for drivers/char/? What has changed in it that makes it ok to move out of the staging tree?

It was dropped from staging :) I don't particularly care to see it go back into staging, as opposed to working out issues out of tree (assuming they are solvable). For one thing, as you note below, there is the question of whether it should be a device driver at all.

Quoted 1 line

And who is going to maintain it? You? Or someone else?

If Ashwin doesn't want to maintain it, I'll do it. Either way.

Quoted 30 lines

Quoted 30 lines

 6 files changed, 578 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/p9auth.txt
 create mode 100644 drivers/char/p9auth/Kconfig
 create mode 100644 drivers/char/p9auth/Makefile
 create mode 100644 drivers/char/p9auth/p9auth.c

Documentation/p9auth.txt new file +18 -0

new file mode 100644
index 0000000..14a69d8
@@ -0,0 +1,47 @@
+The p9auth device driver implements a plan-9 factotum-like
+capability API.  Tasks which are privileged (authorized by
+possession of the CAP_GRANT_ID privilege (POSIX capability))
+can write new capabilities to /dev/caphash.  The kernel then
+stores these until a task uses them by writing to the
+/dev/capuse device.  Each capability represents the ability
+for a task running as userid X to switch to userid Y and
+some set of groups.  Each capability may be used only once,
+and unused capabilities are cleared after two minutes.
+
+The following examples shows how to use the API.  Shell 1
+contains a privileged root shell.  Shell 2 contains an
+unprivileged shell as user 501 in the same user namespace.  If
+not already done, the privileged shell should create the p9auth
+devices:
+
+	majfile=/sys/module/p9auth/parameters/cap_major
+	minfile=/sys/module/p9auth/parameters/cap_minor

Quoted 8 lines

Documentation/p9auth.txt line 23

Quoted 5 lines

Documentation/p9auth.txt new file +5 -0

+	maj=`cat $majfile`
+	mknod /dev/caphash c $maj 0
+	min=`cat $minfile`
+	mknod /dev/capuse c $maj 1
+	chmod ugo+w /dev/capuse

That is incorrect, you don't need the cap_major/minor files at all, the device node should be automatically created for you, right?

Hmm, where? Not in /dev on my SLES11 partition...

Quoted 2 lines

And do you really want to do all of this control through a device node? Why?

Well...

At first I was thinking same as you were. So I was going to switch to a pure syscall-based approach. But it just turned out more complicated. The factotum server would call sys_grantid(), and the target task would end up doing some huge sys_setresugid() or else multiple syscalls using the granted id. It just was uglier. I think there's an experimental patchset sitting somewhere I could point to (if I weren't embarassed :).

Another possibility would be to use netlink, but that doesn't appear as amenable to segragation by user namespaces. The pid (presumably/hopefully global pid, as __u32) is available, so it shouldn't be impossible, but a simple device with simple synchronous read/write certainly has its appeal. Firing off a message hoping that at some point our credentials will be changes, less so.

This is a change which must be discussed. The use of this privilege can be completely prevented by having init remove CAP_GRANT_ID from its capability bounding set before forking any processes.

Can we make this a trivial filesystem? I expect that would match up better with whatever plan9 userspace apps already exist, remove the inode double translation, and would make it much more reasonable to do a user namespace aware version if and when that becomes necessary.

Quoted 4 lines

This is a change which must be discussed. The use of this privilege can be completely prevented by having init remove CAP_GRANT_ID from its capability bounding set before forking any processes.

Which is a minor back compat issue - but you could start without it and allow init to add it.

It seems a very complex interface to do a simple thing. A long time ago there was discussion around extending the AF_UNIX fd passing to permit 'pass handle and auth' so you could send someone a handle with a "become me" token attached.

Alan

drivers/char/p9auth/p9auth.c line 263

Quoted 6 lines · Serge E. Hallyn

drivers/char/p9auth/p9auth.c new file +6 -0

+	if (ret == 0)
+		commit_creds(new);
+	else
+		abort_creds(new);
+
+	return ret;

If you make this:

	if (ret == 0)
		return commit_creds(new);
	abort_creds(new);
	return ret;

then gcc can tail-call commit_creds(), which is guaranteed to return 0.

David

include/linux/cred.h do { \ · line 409

Quoted 6 lines · Serge E. Hallyn

include/linux/cred.h +6 -0

+int cred_setresuid(struct cred *new, uid_t ruid, uid_t euid, uid_t suid,
+		   int force);
+int cred_setresgid(struct cred *new, gid_t rgid, gid_t egid, gid_t sgid,
+		   int force);
+int cred_setfsuid(struct cred *new, uid_t uid, uid_t *old_fsuid);
+int cred_setfsgid(struct cred *new, gid_t gid, gid_t *old_fsgid);

Can you mark these extern please?

Other than that, these functions should probably be mentioned in Documentation/credentials.txt.

David

Quoted 5 lines · Serge E. Hallyn

Quoted 1 line · Greg KH

Hm, who is going to maintain this, you, or Ashwin?

I haven't asked Ashwin, and will be happy either way.  Ashwin, did you want to maintain it?

Well, since you have been driving a lot of implementation changes recently, I feel it makes sense for you to be a maintainer. Honestly I don't think I will be able to find time maintaining this in the future although I can do the code reviews for you. I will be more than happy if this feature continues to get traction.

- Ashwin

Quoted 4 lines

This is a change which must be discussed. The use of this privilege can be completely prevented by having init remove CAP_GRANT_ID from its capability bounding set before forking any processes.

Which is a minor back compat issue - but you could start without it and allow init to add it.

It seems a very complex interface to do a simple thing. A long time ago there was discussion around extending the AF_UNIX fd passing to permit 'pass handle and auth' so you could send someone a handle with a "become me" token attached.

sorry I thought I had cc:d you, bc I was pretty sure you'd have some neat ideas. Like this one.

One could try to argue that this makes every linux process susceptible to a trojan making it grant its userid to other tasks, but of course that's silly since the trojan could just fork. Well, what this would buy the attacker is the ability to sit inconspicuously under his old userid, holding on to the fd until the admin goes out to coffee before switching userids.

The other thing is that offhand I think the server can't easily tell from the socket which user namespace the client is in, as ucred only has .uid. Though (1) we might need to create a 'struct puser' analogous to 'struct pid' for signals anyway, (2) userspace can segragate with fs or net_ns (if abstract sock), and (3) client in a container presumably won't be able to authenticate itself to server on the host anyway.

Quoted 5 lines · Alan Cox

Quoted 4 lines

This is a change which must be discussed. The use of this privilege can be completely prevented by having init remove CAP_GRANT_ID from its capability bounding set before forking any processes.

Quoted 7 lines

Which is a minor back compat issue - but you could start without it and allow init to add it.

It seems a very complex interface to do a simple thing. A long time ago there was discussion around extending the AF_UNIX fd passing to permit 'pass handle and auth' so you could send someone a handle with a "become me" token attached.

If you do go down this path there is a separate (and actually completely opposite) but related problem I might be able and willing to work with you on. When looking at how auditing works in this modern day and age of dbus+polkit to get background processes to do work on behalf of a

user we were discussing an interface that would pass the information about the user to the background server process. The background server process could do some magic such that it still had all the permissions and rights of itself, but had the audit information of the original user. Thus even though it was a server process with uid=0 that did the work, the audit logs could know it was actually on behalf of uid=500.

It was discussed passing that token of audit information over an AF_UNIX socket.

-Eric

Quoted 13 lines · Ashwin Ganti

Quoted 5 lines · Serge E. Hallyn

Quoted 1 line · Greg KH

Hm, who is going to maintain this, you, or Ashwin?

I haven't asked Ashwin, and will be happy either way.  Ashwin, did you want to maintain it?

Well, since you have been driving a lot of implementation changes recently, I feel it makes sense for you to be a maintainer. Honestly I don't think I will be able to find time maintaining this in the future although I can do the code reviews for you. I will be more than happy if this feature continues to get traction.

Quoted 1 line

- Ashwin

Ok.  I'll put myself in MAINTAINERS.  If we stick with the p9auth driver or filesystem approach, I'd like to keep you in MODULE_AUTHOR() if that's ok, bc it really is yours, and wouldn't exist without you.

Quoted 9 lines

sorry I thought I had cc:d you, bc I was pretty sure you'd have some neat ideas. Like this one.

One could try to argue that this makes every linux process susceptible to a trojan making it grant its userid to other tasks, but of course that's silly since the trojan could just fork. Well, what this would buy the attacker is the ability to sit inconspicuously under his old userid, holding on to the fd until the admin goes out to coffee before switching userids.

Possibly, could you put a timestamp in the passed object ? (Given the expiry of such a uid offer is kind of policy)

Quoted 7 lines

The other thing is that offhand I think the server can't easily tell from the socket which user namespace the client is in, as ucred only has .uid. Though (1) we might need to create a 'struct puser' analogous to 'struct pid' for signals anyway, (2) userspace can segragate with fs or net_ns (if abstract sock), and (3) client in a container presumably won't be able to authenticate itself to server on the host anyway.

That I think needs fixing anyway and now is a good time as any to do it. If you are going to be able to pass userids then you need to be sure you don't get passed a handle with a uid change on it that you didn't want so adding another object type and option of some kind to accept them has to occur anyway.

That also btw needs fixing for other reasons - more than one daemon has been written that generically uses recvmsg and so can be attacked with FD leaks >-)

Ignoring namespaces for a moment, I guess we could do something like

struct credentials_pass {
	pid_t global_pid;
	unsigned long unique_id;
	uid_t new_uid;
	gid_t new_gid;
	int num_aux_gids;
	gid_t aux_gids[];
}

Quoted 3 lines

That also btw needs fixing for other reasons - more than one daemon has been written that generically uses recvmsg and so can be attacked with FD leaks >-)

Yup.

(By 'needs fixing' you just mean needs to be done right for this service? Else I think I'm missing something...)

Quoted 10 lines · Serge E. Hallyn

Ignoring namespaces for a moment, I guess we could do something like

struct credentials_pass {
	pid_t global_pid;
	unsigned long unique_id;
	uid_t new_uid;
	gid_t new_gid;
	int num_aux_gids;
	gid_t aux_gids[];
}

This looks surprising like what I am doing in passing uids and pids through unix domain sockets.

So if this looks like a direction we want to go it shouldn't be too difficult.

Quoted 4 lines

Quoted 3 lines

That also btw needs fixing for other reasons - more than one daemon has been written that generically uses recvmsg and so can be attacked with FD leaks >-)

Quoted 4 lines

Yup.

(By 'needs fixing' you just mean needs to be done right for this service? Else I think I'm missing something...)

Remember my unix domain socket and the patch for converting struct cred into a new context, from a month or so ago. I think that is what we are talking about.

Quoted 10 lines · Serge E. Hallyn

Ignoring namespaces for a moment, I guess we could do something like

struct credentials_pass {
      pid_t global_pid;
      unsigned long unique_id;
      uid_t new_uid;
      gid_t new_gid;
      int num_aux_gids;
      gid_t aux_gids[];
}

This looks surprising like what I am doing in passing uids and pids through unix domain sockets.

So if this looks like a direction we want to go it shouldn't be too difficult.

Quoted 13 lines · Eric W. Biederman

Quoted 10 lines · Serge E. Hallyn

Ignoring namespaces for a moment, I guess we could do something like

struct credentials_pass {
      pid_t global_pid;
      unsigned long unique_id;
      uid_t new_uid;
      gid_t new_gid;
      int num_aux_gids;
      gid_t aux_gids[];
}

Quoted 5 lines

This looks surprising like what I am doing in passing uids and pids through unix domain sockets.

So if this looks like a direction we want to go it shouldn't be too difficult.

Hmm... for an alternative idea:

We have this nice "kernel keyring" infrastructure that lets us stuff arbitrary things into "keys" and grant/revoke them between processes. What if we created a relatively generic way for processes to package up privileges (of whatever form) into a "key" that could be granted to another process (via UNIX-domain socket)? Then the other process would use a setuid()-ish syscall which would instead apply a specific key as your credentials, possibly including the audit context and/or namespaces it came from.

By using the keyring system, such tokens could be kept around across multiple processes easily (as opposed to FDs), in the same style as a "sudo" ticket file, for example (even with an expiration time).

Types of credentials you could pass around:
* Capabilities
* Filesystem UID/GID in a particular UID namespace (for FS operations)
* Process UID/GID in a particular UID namespace (for kill(), etc)
* Audit contexts
* SELinux/etc security labels

All of the above could be optionally limited to effectively require a bprm-secure-style exec() with specific args. So for example, instead of making "/usr/sbin/passwd" a setuid program, you could make it be an unprivileged helper. It would connect to a privileged daemon and ask for a password-change cookie for that particular user. The daemon would create what is essentially a "delayed exec" key which grants a specific UID and capabilities when that process performs an execkey().

So as an example, you could rewrite "sudo" as a partially-privileged daemon and an unprivileged helper. The unpriv helper would send across a request (optionally including the command and environment) which would be checked by the daemon. It would then issue a key to allow the unpriv helper to perform a limited exec.

Another option would be to rewrite network login programs (eg OpenSSH) to use this for privilege separation. The listening process would get a non-expiring key to allow it to exec a partially-privileged password-checking program. If the password-checking program likes the password it generates a single-use key to pass back to the forked network process that allows it to exec a program as that user.

Quoted 88 lines · Serge E. Hallyn

Quoted 8 lines · Greg KH

Quoted 3 lines · Serge E. Hallyn

This is a driver that adds Plan 9 style capability device implementation. See Documentation/p9auth.txt for a description of how to use this.

Hm, you didn't originally write this driver, so it would be good to get some original authorship information in here to keep everything correct, right?

That's why I left the MODULE_AUTHOR line in there - not sure what else to do for that. I'll add a comment in p9auth.txt, especially pointing back to Ashwin's original paper.

Quoted 9 lines

Quoted 6 lines

 Documentation/p9auth.txt     |   47 ++++
 drivers/char/Kconfig         |    2 +
 drivers/char/Makefile        |    2 +
 drivers/char/p9auth/Kconfig  |    9 +
 drivers/char/p9auth/Makefile |    1 +
 drivers/char/p9auth/p9auth.c |  517 ++++++++++++++++++++++++++++++++++++++++++

Is this code really ready for drivers/char/? What has changed in it that makes it ok to move out of the staging tree?

It was dropped from staging :) I don't particularly care to see it go back into staging, as opposed to working out issues out of tree (assuming they are solvable). For one thing, as you note below, there is the question of whether it should be a device driver at all.

Quoted 1 line

And who is going to maintain it? You? Or someone else?

If Ashwin doesn't want to maintain it, I'll do it. Either way.

Quoted 30 lines

Quoted 30 lines

 6 files changed, 578 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/p9auth.txt
 create mode 100644 drivers/char/p9auth/Kconfig
 create mode 100644 drivers/char/p9auth/Makefile
 create mode 100644 drivers/char/p9auth/p9auth.c

Documentation/p9auth.txt new file +18 -0

new file mode 100644
index 0000000..14a69d8
@@ -0,0 +1,47 @@
+The p9auth device driver implements a plan-9 factotum-like
+capability API.  Tasks which are privileged (authorized by
+possession of the CAP_GRANT_ID privilege (POSIX capability))
+can write new capabilities to /dev/caphash.  The kernel then
+stores these until a task uses them by writing to the
+/dev/capuse device.  Each capability represents the ability
+for a task running as userid X to switch to userid Y and
+some set of groups.  Each capability may be used only once,
+and unused capabilities are cleared after two minutes.
+
+The following examples shows how to use the API.  Shell 1
+contains a privileged root shell.  Shell 2 contains an
+unprivileged shell as user 501 in the same user namespace.  If
+not already done, the privileged shell should create the p9auth
+devices:
+
+	majfile=/sys/module/p9auth/parameters/cap_major
+	minfile=/sys/module/p9auth/parameters/cap_minor

Quoted 8 lines

Documentation/p9auth.txt line 23

Quoted 5 lines

Documentation/p9auth.txt new file +5 -0

+	maj=`cat $majfile`
+	mknod /dev/caphash c $maj 0
+	min=`cat $minfile`
+	mknod /dev/capuse c $maj 1
+	chmod ugo+w /dev/capuse

That is incorrect, you don't need the cap_major/minor files at all, the device node should be automatically created for you, right?

Hmm, where? Not in /dev on my SLES11 partition...

Quoted 2 lines

And do you really want to do all of this control through a device node? Why?

Well...

At first I was thinking same as you were. So I was going to switch to a pure syscall-based approach. But it just turned out more complicated. The factotum server would call sys_grantid(), and the target task would end up doing some huge sys_setresugid() or else multiple syscalls using the granted id. It just was uglier. I think there's an experimental patchset sitting somewhere I could point to (if I weren't embarassed :).

Quoted 6 lines

Another possibility would be to use netlink, but that doesn't appear as amenable to segragation by user namespaces. The pid (presumably/hopefully global pid, as __u32) is available, so it shouldn't be impossible, but a simple device with simple synchronous read/write certainly has its appeal. Firing off a message hoping that at some point our credentials will be changes, less so.

pid in the netlink context is the netlink port-id. It is a very different concept from struct pid. These days netlink calls to the kernel are synchronous, not that I would encourage netlink for anything except networking code.

Can we make this a trivial filesystem? I expect that would match up better with whatever plan9 userspace apps already exist, remove the inode double translation, and would make it much more reasonable to do a user namespace aware version if and when

that becomes necessary.

An fs actually seems overkill for two write-only files for process-related information.  Would these actually be candidates for new /proc files?

       /proc/grantcred - replaces /dev/caphash, for privileged tasks to tell the kernel about new setuid capabilities
       /proc/self/usecred - replaces /dev/capuse for unprivileged tasks to make use of a setuid capability

Quoted 9 lines · Serge E. Hallyn

An fs actually seems overkill for two write-only files for process-related information.  Would these actually be candidates for new /proc files?

       /proc/grantcred - replaces /dev/caphash, for privileged tasks to tell the kernel about new setuid capabilities
       /proc/self/usecred - replaces /dev/capuse for unprivileged tasks to make use of a setuid capability

An fs is fine.

To relate this to Plan 9, where it all began, might be useful. There's no equivalent in Plan 9 to Linux/Unix devices of the major/minor number etc. variety. In-kernel drivers and out-of-kernel servers both end up providing the services (i.e. file name spaces) that we see in a Linux file system. So the Plan 9 driver for the capability device really does match closely in function and interface to a Linux kernel-based file system.

Hence, making devcap a file system is entirely appropriate, because it best fits the way it works in Plan 9: a kernel driver that provides two files.

It's pretty easy to write a Linux VFS anyway, so it makes sense from that point of view.

Eric, that was a great suggestion.

Quoted 22 lines · ron minnich

Quoted 9 lines · Serge E. Hallyn

An fs actually seems overkill for two write-only files for process-related information. ??Would these actually be candidates for new /proc files?

?? ?? ?? ??/proc/grantcred - replaces /dev/caphash, for privileged ?? ?? ?? ?? ?? ?? ?? ??tasks to tell the kernel about new setuid ?? ?? ?? ?? ?? ?? ?? ??capabilities
?? ?? ?? ??/proc/self/usecred - replaces /dev/capuse for unprivileged ?? ?? ?? ?? ?? ?? ?? ??tasks to make use of a setuid capability

An fs is fine.

To relate this to Plan 9, where it all began, might be useful. There's no equivalent in Plan 9 to Linux/Unix devices of the major/minor number etc. variety. In-kernel drivers and out-of-kernel servers both end up providing the services (i.e. file name spaces) that we see in a Linux file system. So the Plan 9 driver for the capability device really does match closely in function and interface to a Linux kernel-based file system.

Quoted 8 lines

Hence, making devcap a file system is entirely appropriate, because it best fits the way it works in Plan 9: a kernel driver that provides two files.

It's pretty easy to write a Linux VFS anyway, so it makes sense from that point of view.

Eric, that was a great suggestion.

A fs provides user space policy control of naming. I.e. where the two files go. That can also be a very big deal. Especially when files are writable.

You have no idea how much I am frustrated by sysfs right now, because it does not provide userspace policy control and instead mandates a sometimes inappropriate naming convention.

Eric