Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 516616 - [Future EAPI] 'esudo' to limit the scope of raised privileges
Summary: [Future EAPI] 'esudo' to limit the scope of raised privileges
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2014-07-07 14:18 UTC by Michał Górny
Modified: 2014-07-07 22:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-07 14:18:56 UTC
Right now, whenever we need superuser privileges, we usually raise them for the scope of the whole phase function (pkg_*) or ebuild (RESTRICT=userpriv). Usually this is unnecessary and sometimes it is much undesired.

So my idea is to run all phases with the build user privileges, and provide a new 'esudo' helper that would elevate privileges for a command/function call. Of course, this will require some fancy hackery to allow raising privileges. Commands called by ebuilds may be potentially capable of abusing this -- but well, the goal is to catch mistakes and not malice.

Usage could be like:

  esudo [-u USER] [-g GROUP] [-G SUPPL_GROUPS] [-c CAPS] COMMAND...

where specifically:

1. -u sets EUID to given user, and EGID matching passwd,

2. -g sets EGID to given group, possibly overriding (1),

3. -G sets list of supplementary groups,

4. -c tries to enable given capabilities. If capabilities are not supported, forces superuser instead,

5. If no options are passed, defaults to gaining superuser privileges.

I'm not sure how far this should go. It would be definitely better than e.g. RESTRICT=userpriv for the whole ebuild, and cleaner than trying to invent special variable syntax to limit it to phases.

It may add unnecessary complexity in pkg_* phases. On the other hand, very often those phases either just output something (which doesn't need elevated privileges) or calls eclass functions (where we could just put our 'esudo' inside).