# Port of OpenBSD's doas



## NewGuy (Jun 22, 2016)

Last year the OpenBSD developers created an alternative to "sudo" called "doas". The doas program has a simpler configuration file and is quite small, keeping the code tiny and, one hopes, secure.

I have ported the OpenBSD 5.9 version of doas over to FreeBSD 10.3 (with a lot of help from the NetBSD doas port). The FreeBSD port is available for testing if anyone wants to try it out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210473

I'm using doas on my FreeBSD box and it's been working well for me. It's pretty much a drop-in replacement for sudo, just with a simpler config file.


----------



## Oko (Jun 22, 2016)

NewGuy said:


> It's pretty much a drop-in replacement for sudo, just with a simplier config file.


Thanks for the port. However people who stumble onto this post should not be mistaken that *doas* is full blown replacement for *sudo*.  By the way *sudo* is also mantained by OpenBSD developer Todd Miller but it is not a sub-project of OpenBSD like OpenSSH or LibreSSH for example. *sudo* is licensed under the same type ISC style license like OpenBSD.


----------



## NewGuy (Jun 22, 2016)

As you say, doas is not a sub-project of OpenBSD, it is an actual part of OpenBSD and is built into the default installation. As for whether it's a full replacement for sudo, I think (for most people) it'll be on parity. Unless you need some obscure corner case use for sudo, they have the same features.


----------



## tobik@ (Jun 22, 2016)

NewGuy said:


> Unless you need some obscure corner case use for sudo, they have the same features.


A lot of people use sudo's credential caching which I wouldn't exactly call a corner case. Does doas support this now? It might be surprising to some that with doas they have to type in their password every time.

I had a quick look at the port. Running ports-mgmt/portlint gives a lot of errors:

```
WARN: Makefile: [22]: possible use of "${CHMOD}" found. Use @(owner,group,mode) syntax or @owner/@group operators in pkg-plist instead.
FATAL: Makefile: extra item "MAINTAINER" placed in the PORTNAME section.
FATAL: Makefile: extra item "COMMENT" placed in the PORTNAME section.
FATAL: Makefile: extra item "LICENSE" placed in the MAINTAINER section.
WARN: Makefile: COMMENT is set externally to this port's Makefile, but this port is not configured as a slave port.
FATAL: Makefile: extra item "USE_GITHUB" placed in the LICENSE section.
FATAL: Makefile: extra item "GH_ACCOUNT" placed in the LICENSE section.
FATAL: Makefile: extra item "GH_PROJECT" placed in the LICENSE section.
FATAL: Makefile: extra item "GH_TAGNAME" placed in the LICENSE section.
7 fatal errors and 2 warnings found.
```
 You don't need to set GH_PROJECT since it's inferred from PORTNAME. LICENSE should be ISCL instead of BSD2CLAUSE.

Regarding the code I'm curious why all usages of reallocarray() have been replaced with realloc()? Why did you include and compile reallocarr.c? Nothing calls reallocarr() AFAICT.

A version of reallocarray() that will likely work on FreeBSD too can be found here: https://github.com/chneukirchen/outils/blob/master/src/liboutils/reallocarray.c  or in the OpenBSD source tree in lib/libc/stdlib/reallocarray.c.

Thank you for doing this. I might just switch to doas and get rid of sudo when it's committed.


----------



## NewGuy (Jun 22, 2016)

I'll move stuff around in the Makefile and fix the CHMOD error. Odd that it works here. Ah well, that's part of the fun, tuning this stuff to work across the board.

I swapped out reallocarry() because it (as it was originally in the code) won't compile on FreeBSD. Originally, I had planned to use reallocarr.c to handle it, but it seemed easier to simply use the built-in realloc() function instead, since it does the same thing. This was my first, rough pass at the port and I just wanted to get it working. (There are a surprising number of OpenBSD calls/variables that simply do not work/exist on FreeBSD.) In the second version I can either use reallocarray() or drop the reallocarr.c file.

I don't think doas handles credential caching, but it's possible to either use the nopassword flag or run "doas su" if you need to run doas a lot without putting in a password over and over. Whenever I find myself using "sudo" a lot, I just run either "sudo -i" or "sudo su" rather than running "sudo" over and over.


----------



## tobik@ (Jun 22, 2016)

NewGuy said:


> Originally, I had planned to use reallocarr.c to handle it, but it seemed easier to simply use the built-in realloc() function instead, since it does the same thing.


It doesn't do the same thing. reallocarray()/reallocarr() also check for integer overflows. realloc() doesn't.

I found a small mistake in parse.y's realloc() usage (+ instead of *):

```
--- parse.y.orig	2016-06-23 00:33:25.452701424 +0200
+++ parse.y	2016-06-23 00:33:40.818691888 +0200
@@ -130,7 +130,7 @@
 			/* if (!($$.envlist = reallocarray($1.envlist, nenv + 2,
 			    sizeof(char *))))
                         */
-                        if (!($$.envlist = realloc($1.envlist, (nenv + 2) + sizeof(char*))))
+                        if (!($$.envlist = realloc($1.envlist, (nenv + 2) * sizeof(char*))))
 				errx(1, "can't allocate envlist");
 			$$.envlist[nenv] = $2.str;
 			$$.envlist[nenv + 1] = NULL;
```


----------



## NewGuy (Jun 22, 2016)

Functionally realloc does the same thing, just without the check.

Thanks for pointing out the type, I'll address it in the next snapshot.


----------



## NewGuy (Jun 23, 2016)

Regarding the above warning about using "Use @(owner,group,mode) syntax" instead of chmod, I wonder if that is right? I checked the Porter's Handbook and there doesn't appear to be any mention of the @() syntax for dealing with file permissions. Also, I checked the port on another FreeBSD box and running "make install" with the existing chmod syntax works as expected.

I've updated the license though and patched some of the code, so I should have an updated port sometime tomorrow.


----------



## Oko (Jun 23, 2016)

NewGuy said:


> As you say, doas is not a sub-project of OpenBSD


Please read my post again. I said *sudo* is not a sub-project of OpenBSD even though it is maintained by OpenBSD developer Todd Miller and has the same  ISC style license like OpenBSD.


----------



## NewGuy (Jun 23, 2016)

My mistake, I misread your comment about sudo.


----------



## lme@ (Jan 30, 2017)

NewGuy: Thanks for porting doas! Is there any chance that we can get an updated version? Upstream has the "persist" keyword in doas.conf which caches the password for some time. It would be really nice to see this in the FreeBSD port.


----------



## NewGuy (Jan 30, 2017)

Someone submitted a patch on GitHub to marge in the persist keyword, but it doesn't work yet. Waiting for an update to see if they can sort out the issues. You're welcome to test it and submit fixes. The OpenBSD version of doas has been reorganized somewhat and it means merging in new features it's a simple patch-and-go job.


----------



## abishai (Jan 30, 2017)

We don't have *TIOCCHKVERAUTH* request. This is OpenBSD'ism. So, we should port it to the kernel first or implement another platform agnostic method.
https://github.com/slicer69/doas/pull/9/files#diff-96441aabc70756048783b0032e39ecfaR258


----------



## Deleted member 48958 (May 3, 2017)

Anyway, now,  security/doas seems to be working fine, it replaced sudo for me.

If someone wants  to get rid of sudo,
just remove it, install doas and create /usr/local/etc/doas.conf
with

```
permit keepenv :wheel
```
in it, or

```
permit keepenv [i]your_username[/i]
```
or

```
permit [i]your_username[/i]
```
 try doas.conf(5).

Thank you very much, NewGuy!

Optionally create alias for your shell, for example

```
alias sudo 'doas'
```

But also, it is always possible to use
`# su - root -c '[i]your command[/i]'`


----------



## SirDice (May 3, 2017)

ILUXA said:


> But also, it is always possible to use
> `# su - root -c '[I]your command[/I]'`


Only if you're a member of the wheel group and know root's password.


----------



## Deleted member 48958 (May 3, 2017)

SirDice said:


> ILUXA said:
> 
> 
> > But also, it is always possible to use
> ...


Absolutely! To add a user to the wheel group, "`# pw groupmod wheel -m [i]your_username[/i]`" should be executed.


----------

