Support for doas in addition to (instead of) sudo

[wrbbz]

Please describe your use case / problem.
I'm really like telepresence and its features. I'm using it all the time. But, sadly, I can connect with one line only on MacOS machine. Because on my primary Linux machine I'm using doas instead of sudo. Thus, to run telepresence as I do on MacOS, I have to run daemon-foreground and only after that - telepresence connect:

❯ doas telepresence daemon-foreground <logging dir> <config dir>

And only after that I can connect
Looks like some workarounds for me.
I even tried to make symlink from doas to sudo. However, it did not work, I suppose, because there is no option --non-interactive in doas. Only -n which does the same.

Describe the solution you'd like
It could be nice to have a possibility to override privileges escalation tool. For example, by default it could be sudo, but in some cases you can override it to doas.

Versions (please complete the following information)

❯ telepresence version
OSS Client     : v2.18.0
Root Daemon    : not running
OSS User Daemon: v2.18.0
Traffic Manager: not connected

[thallgren]

Did you try using a sudoers file that will allow you do sudo without password? E.g.

%admin ALL=(ALL) NOPASSWD: ALL

[ejiek]

@thallgren I'm sorry, but I'm a bit confused by your suggestion =\

sudoers file is used by sudo which @wrbbz doesn't have because he uses an alternative - doas.

doas has a similar file /etc/doas.conf but it isn't helpful because telepresence calls sudo binary.

It's not possible to work around it with a simple sudo to doas alias because they have different sets of arguments.
telepresence uses sudo with --non-interactive argument while doas doesn't have this exact argument so it fails.

doas has somewhat similar -n:

Non interactive mode, fail if the matching rule doesn't have
the nopass option.

The problem boils down to a hard sudo dependency in startInBackgroundAsRoot function.
I see at least two possible solutions:

• make privilege escalation command user-configurable
• hardcode both utils: try to look for sudo, in case of failure look for doas, then fail miserably

ps. I'm also a doas user and lack sudo on my machine.
pps. I'm happy to implement this alternative privilege escalation feature after figuring out the solution here.

[thallgren]

@ejiek I misunderstood the problem. Thought it was about the password prompt.

This looks like a good candidate for a PR contribution that makes the command configurable from config.yml. Would you be interested in trying that?

[ejiek]

@thallgren it absolutely fine & thanks for the suggestion =]

Going to try if it even works by just hardcoding doas with relevant arguments. If it does I'll take a look at the config file.

[ejiek]

Good news, swapping sudo for doas and changing non interactive argument works.
Now we have to figure out how to integrate it into config.
PR is brewing.