This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Friendlier EPERM.

Hash: SHA1

Traditionally, if a process attempts a forbidden  operation, errno for that
thread is set to EACCES or EPERM, and a call to strerror() returns a localized
version of "Permission Denied" or "Operation not permitted". This string
appears throughout textual uis and syslogs. For example, it will show up in
command-line tools, in exceptions within scripting languages, etc.

There are an increasing number of ways in which you can fail to have
permission to do something:

    classic POSIX discretionary access controls
    Linux security modules (e.g. SELinux mandatory access controls)
    seccomp denials

As we continue to add mechanisms for the Kernel to deny permissions, the
Administrator/User is faced with just a message that says "Permission Denied"
Then if the administrator is lucky enough or skilled enough to know where to
look, he might be able to understand why the process was denied access.

In Fedora we had an idea about making it possible for strerror() to contain
richer information about permissions failures.


We would like to open up discussion about this with the glibc developers to
see what they think of the idea before opening it up to a larger community.

How does this sound from a glibc perspective?

Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with undefined -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]