From Fedora Project Wiki
(initial page creation)
 
Line 55: Line 55:
== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
This feature should significantly simplify debugging permissions issues in Fedora.  For example, rather than seeing "Operation not permitted" error and e.g. blindly trying to disable SELinux, a user can see directly whether or not SELinux was involved.


== Scope ==
== Scope ==

Revision as of 19:20, 7 January 2013

Important.png
Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.
Important.png
Set a Page Watch
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
Note.png
All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed



Friendly EPERM

Summary

Coordinated patches to kernel and glibc so that (optionally) strerror(EPERM) gives useful information on why permission was denied

Owner

  • Email: <dmalcolm@redhat.com>

Current status

  • Targeted release: [[Releases/<number> | Fedora <number> ]]
  • Last updated: (DATE)
  • Percentage of completion: XX%


Detailed Description

Traditionally, if a process attempts a forbidded operation, errno for that thread is set to EPERM, and a call to strerror() returns a localized version of "Operation not permitted". This string appears throughout textual UIs. 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)
  • capabilities
  • etc (TODO: expand this list)

Under normal deployment situations we don't want to leak information to an attacker as to why permission was denied, but under development situations it's useful to know why a failure happens.

We propose to:

  • patch the kernel so that it can optionally provide user-space with a "failure cookie" giving additional information beyond the bare ERRNO (handled at the per-thread level, like strerror, iirc)
  • patch glibc's implementation of strerror (and related calls) so that it can use this "failure cookie" to provide a localized extension to the "Operation not permitted" giving additional details.

For example: TODO

The failure cookie would only be exposed to user space for processes with a particular bit set (using prctl), so that you have to opt-in to having this information exposed.


Benefit to Fedora

This feature should significantly simplify debugging permissions issues in Fedora. For example, rather than seeing "Operation not permitted" error and e.g. blindly trying to disable SELinux, a user can see directly whether or not SELinux was involved.

Scope

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

Comments and Discussion