| 1 |
On 07/09/2014 07:17 AM, Micha³ Górny wrote: |
| 2 |
>>> c) 'esudo' helper [3]. This is a more generic form of (2), with |
| 3 |
>>> support for other potential privilege changes. |
| 4 |
>> |
| 5 |
>>> [...] |
| 6 |
>> |
| 7 |
>>> Disadvantages: |
| 8 |
>> |
| 9 |
>>> - hard to implement -- especially if we want to make it capable of |
| 10 |
>>> running bash functions. |
| 11 |
>> |
| 12 |
>> Any idea how to implement it? Does it imply adding app-admin/sudo to |
| 13 |
>> the system set? |
| 14 |
> |
| 15 |
> I don't think we'd use the reference 'sudo' impl. Rather some |
| 16 |
> in-portage helper, possibly setuid. Or portage's IPC but that would |
| 17 |
> imply running the command in an isolated environment (possibly |
| 18 |
> beneficial). |
| 19 |
|
| 20 |
The environment doesn't necessarily have to be isolated, since we could |
| 21 |
extend the existing environment saving/loading support to be used for by |
| 22 |
esudo. The steps to implement the shared environment could be as follows: |
| 23 |
|
| 24 |
1) When esudo is called, it saves the current (unprivileged) bash |
| 25 |
environment to a file. |
| 26 |
|
| 27 |
2) esudo uses IPC to request that a process with elevated privileges be |
| 28 |
launched to run a specific command using the saved environment, and that |
| 29 |
the environment of the elevated process be saved to a file after the |
| 30 |
command completes. |
| 31 |
3) Before esudo returns, it loads the environment that was saved by the |
| 32 |
elevated process before it exited. |
| 33 |
|
| 34 |
Of course, we could also use pipes as a substitute for saving the |
| 35 |
environments to temporary files. |
| 36 |
-- |
| 37 |
Thanks, |
| 38 |
Zac |
Archives