[pacman-dev] [PATCH] Adding support for sudo when user is not root and root privileges are required

[Allan McRae]

On 22/03/15 11:44, Lorenzo Mureu wrote:
> This patch adds support for sudo in pacman.
> Now, when you run some unharmful (informative) command with pacman all
> is fine, but if you try some potentially harmful command (like
> installing or removing packages, or syncing) it stops telling you that
> you must be root.
> 
> While this behaviour is perfectly fine, and that can be what most users
> want, I'd prefere that when root previleges are needed pacman acquired
> them directly with sudo.
> 
> This is accomplished this way:
> 1) A new configuration file option is provided: UseSudo.
>    If it is not set pacman will behave normally, as always (i.e. prints
>    an error)
>    It is set than it will use sudo if needed
> 
> 2) As a direct consequence of 1) the configuration structure defined in
>    config.h and config.c has a new field: usesudo.
>    == 1 means "use sudo"
>    == 0 means "never use sudo"
>    Its value is set according to the configuration file.
>    That is: if user set UseSudo in pacman.conf then usesudo=1 else
>    usesudo=0
> 
> 3) In pacman.c I created a copy of argv (because getopt re-arranges the
>    array) and extended it so that, when passed as a parameter to execvp,
>    it will run as if it was ` exec sudo pacman "$@" ` in bash
>    There ARE some problems, but I could eventually fix them, if needed,
>    if the patch was to be accepted.
> 
>    1) sargv, the "sudo"-execvp-copy of argv is always created and populated.
>       It wouldn't be necessary if getopt didn't re-order argv's elements
>       I could put its allocation and initialization inside an if that
>       checks usesudo, but I don't know if that is OK with pacman's
>       main() flow.
> 
> Anyway, I hope this patch isn't too ugly (this is the first I cooperate
> to a big program). If it is, please tell me and I'll fix it.
> 

Hi,

Thanks for the contribution.  I suggest in future that you always
discuss adding features like this with the main project developers
before preparing a patch.

In this case, I see very limited advantage of this approach over using
an alias.

Allan