Re: Friendlier EPERM.

On Tue, 2013-01-08 at 10:36 -0800, Roland McGrath wrote:

> You can certainly add some additional side channel of some kind with
> more information about failures.  But you really cannot shoehorn this
> sort of thing into standard interfaces.  It's just not that easy, sorry.

Side channel was clearly the idea.  But you are right about holding onto
errno for a long time.  Not certain how that would work out.  I guess we
can't make it part of the default perror/strerror processing and we are
going to have to change every usespace application to take advantage of
friendlier EPERM.  :-(   But that's life.

My thought was in the kernel to create a new buffer to dump some info
when a EPERM/EACCES is going to be returned.  Userspace may or may not
ever read it and it might be overwritten the next EPERM/EACCES.  I was
thinking we could expose a representation of this buffer in
a /proc/self/task/[tid]/blob file.  This file could be read after the
EPERM/ACCESS.  It would have a layout which differed based on the reason
for the denial.  I'd see it as something like (very very pseudo codie)

struct friendly_response {
	enum { CAPABILITIES, SELINUX, FILE_PERMS }
	union {
		struct capabilities {
			int cap;
		};
		struct selinux {
			char *source_label
			char *target_label
			char *operation;
			char *tclass;
		};
		struct file_perms {
			int uid;
			int gid;
			int file_uid;
			int file_gid;
			int file_mode;
		};
	};
};

So userspace (maybe a new library call?) could parse the proc file and
give a little more useful information.  Clearly not race free, but it
would work most of the time.  Shouldn't be hard for glibc to turn such a
string/structure into a translated message....

So a read of the proc file after a denial from file permissions would
return a string like

1 500 500 0 0 0600

Or from SELinux

0 unconfined_u:unconfined_r:unconfined_t:s0 system_u:system_r:system_t:s0 { read } file

Should have minimal translations needed to turn that into a usable string.

-Eric