Yay: doas support

Created on 22 Feb 2020  路  26Comments  路  Source: Jguer/yay

Hi! First off, I would like to thank you for the amazing work and effort you put into yay. It makes managing AUR packages a breeze!

Thanks to this video by DistroTube I learned about doas, a (much) smaller alternative to sudo. Or, as DT puts it, with "less bloat". (already available in the AUR)
I'm interested in replacing sudo with doas on my system, but right now yay-bin is the only program that explicitly depends on sudo and effectively makes the move impossible; unless I keep both sudo and doas. I find that that would defeat the purpose of choosing a more minimal program, however.

Would it be possible for yay to support doas too? Or maybe even better to allow the user to set the program used to gain root privileges via an option in the config file, just in case a third alternative to sudo pops up in the future. That would avoid hard-coding the program used directly in yay's source code.

Approved Enhancement good first issue help wanted

Most helpful comment

Just a note about the workaround, the --sudobin and --sudoargs arguments were renamed in the latest version of yay, this is the correct command to save doas as replacement for sudo:

yay --sudo doas --sudoflags -- --save

All 26 comments

yay --sudobin doas --save

Thanks! I wasn't aware of that option. There's still the problem of yay requiring sudo.
Also, I found out that doas needs to be invoked slightly differently. In fact, it requires two dashes before the command you want to execute with root privileges. (e.g. doas -- pacman -Syu) so if yay were to invoke doas the same way it does with sudo, the command would fail.

@brainplot: you could solve this locally via a shim command in /usr/local/bin or similar:

#!/bin/sh
# this is /usr/local/bin/sudo
exec doas -- "$@"

it's not perfect, and will not work if programs try to use some of sudos options, but for basic usage it should work.

Or yay --sudoargs -- --save

Thanks for the suggestions. I think I will use a combination of @parkerlreed and @Morganamilo's solutions.

At this point there's only the issue of the dependency on sudo. I guess I could code up a custom PKGBUILD that provides sudo in order to satisfy the dependency, as a temporary (or maybe permanent?) solution.

doas is also available from the official repos as opendoas.

@brainplot or you can ask the maintainer of opendoas if he's willing to set this.

The best solution would be a virtual package like cron which can be set as a dependency but doesn't exist and the user needs to decide which package, which provides cron he wants.

@RubenKelevra that would be ideal. Although a patch in yay which detects what the user has installed to elevate privileges would be nice since as is it would require the user to create a config file and change the sudo binary and arguments. I think that would make yay a bit less user-friendly as it works perfectly fine out of the box, otherwise.

On the other hand, if you've replaced sudo with doas on your system I guess you know what you're doing already thus you'd know how to "fix" yay.

On the other hand, if you've replaced sudo with doas on your system I guess you know what you're doing already thus you'd know how to "fix" yay.

Or you just create a small package which adds the link from sudo to doas in the filesystem and sets 'replace = sudo' and 'provide = sudo' as well a dependency for opendoas.

This should fix all of your problems and is not application dependent.

Edit: yay could then go ahead and check if sudo is just a link and if it knows the binary it could use it directly.

Currently the only thing that doesn't seem to work is the --sudoloop command, is there any way to fix this? I'd like to just remove sudo.

I think --sudoloop is run with sudo -v, is there an equivalent mechanism in doas to keep authentication?

Just a note about the workaround, the --sudobin and --sudoargs arguments were renamed in the latest version of yay, this is the correct command to save doas as replacement for sudo:

yay --sudo doas --sudoflags -- --save

@Jguer can you remove the dependency for sudo on the aur package please?

It should be an optional dependency and maybe opendoas should be another optional dependency, since yay can work with both :)

Just a note about the workaround, the --sudobin and --sudoargs arguments were renamed in the latest version of yay, this is the correct command to save doas as replacement for sudo:

yay --sudo doas --sudoflags -- --save

I think yay should just check if no sudo is installed, but opendoas is, and just set this on the first run on such a system. :)

I think yay should just check if no sudo is installed, but opendoas is, and just set this on the first run on such a system. :)

Yes, this would be ideal, as well as making sudo and opendoas optional dependencies. I manually edited my PKGBUILD to remove sudo.

@TheDcoder you can also just remove sudo with pacman -Sd sudo which skips the dependency checks while doing this operation.

@RubenKelevra Right, I did not take a look at all the options, but I did find out about --assume-installed option shortly after I made my modification.

Can we get a --doasloop that works with

--sudoupdateflags=true

As suggested in the post I linked? It's the only reason I still have sudo haha

I've discovered two issues when using opendoas instead of sudo with yay:

  • sudoloop is running too slow, opendoas has a lower timeout when using persis
  • running yay as root will return an error since it tries to run opendoas as root

Can we get a --doasloop that works with

@Kommynct OpenDoas currently has experimental support for persistant authorization, and it is not enabled by default, so it might not be a good idea to add support for this feature until it is stable enough.

So it seems for me from https://github.com/Duncaen/OpenDoas/issues/29 that running doas true with a shorter cycle than sudo loop would work? Is that right?

@Jguer The --with-timestamp flag is also needed to enable timeout support, otherwise doas will prompt you for the password on each call. Also take note that this feature is experimental and dangerous:

This feature is new and potentially dangerous, in the original doas, a kernel API is used to set and clear timeouts. This API is openbsd specific and no similar API is available on other operating systems. Source

Ok, so I agree that this may need some aging time before support is implemented

Well, I don't see a reason why yay shouldn't support an experimental feature. I mean, when we don't experiment with it - it won't ever get stable, right? 馃

Does someone have a proper workaround?
Currently I set in yay config

    "sudobin": "$HOME/.local/bin/yay-doas-wrapper",

and my wrapper is as follows

#!/bin/sh
#
#  This wrapper makes sure yay+pacui works with doas
#

if [ "$1" = "-v" ]
then
    shift
fi

if [ "$1" = "--" ]
then
    shift
fi

if [ -z "$1" ]
then
    exec doas echo
else
    exec doas "$@"
fi

also my doas conf

permit persist :wheel
Was this page helpful?
0 / 5 - 0 ratings