This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Friendlier EPERM.
- From: Eric Paris <eparis at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Daniel J Walsh <dwalsh at redhat dot com>, libc-alpha at sourceware dot org, DavidMalcolm <dmalcolm at redhat dot com>
- Date: Tue, 08 Jan 2013 14:34:29 -0500
- Subject: Re: Friendlier EPERM.
- References: <50EC5E21.4040002@redhat.com> <20130108183625.DF03D2C08D@topped-with-meat.com>
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