Hi gang,
So... I'm biased: I plain out don't like security/sudo, never have. Instead I heavily relied on /usr/bin/su but also on lowering requirements. For example: make a ports group, give it rw access to /var/db/ports and you don't have to bother with root to (re)configure your ports as long as you're part of that group.
... then I discovered security/doas, and I became a huge fan!
So: could I somehow implement this into the "ports workflow"? You know what I love about FreeBSD? There is so much information out there, all you have to do... is go look for it: /usr/ports/Mk/bsd.commands.mk. Check this out:
	
	
	
		
One visit to su(1) later and I realized that the default -c was actually an argument, not a class definition. 
So then I visited /usr/ports/Mk/bsd.port.mk which is where I found this snippet within do-config::
	
	
	
		
So that's why they're firing up an extra sh instance with their sudo example.
Surely we can do the same with doas? Guess what, we can! => SU_CMD=/usr/local/bin/doas -n sh -c.
This will work miracles if you have something like this in your /usr/local/etc/doas.conf: permit nopass :wheel.
In other words: root permit restrictions in place, but without the hassle of needing constant password authentication.
I'm actually in the process of "kerberizing" this process courtesy of security/krb5 and a shell script, but that's a story for another time Work in progress so far.
  Work in progress so far.
Hope this could be useful for some of you!
				
			So... I'm biased: I plain out don't like security/sudo, never have. Instead I heavily relied on /usr/bin/su but also on lowering requirements. For example: make a ports group, give it rw access to /var/db/ports and you don't have to bother with root to (re)configure your ports as long as you're part of that group.
... then I discovered security/doas, and I became a huge fan!
So: could I somehow implement this into the "ports workflow"? You know what I love about FreeBSD? There is so much information out there, all you have to do... is go look for it: /usr/ports/Mk/bsd.commands.mk. Check this out:
		Code:
	
	# Command to run commands as privileged user
# Example: "/usr/local/bin/sudo -E sh -c" to use "sudo" instead of "su"
SU_CMD?=                /usr/bin/su root -cSo then I visited /usr/ports/Mk/bsd.port.mk which is where I found this snippet within do-config::
		Code:
	
	                ${ECHO_MSG} "===>  Switching to root credentials to create $${optionsdir}"; \
                (${SU_CMD} "${SH} -c \"${MKDIR} $${optionsdir} 2> /dev/null\"") || \
                        (${ECHO_MSG} "===> Cannot create $${optionsdir}, check permissions"; exit 1); \
                ${ECHO_MSG} "===>  Returning to user credentials" ; \Surely we can do the same with doas? Guess what, we can! => SU_CMD=/usr/local/bin/doas -n sh -c.
This will work miracles if you have something like this in your /usr/local/etc/doas.conf: permit nopass :wheel.
In other words: root permit restrictions in place, but without the hassle of needing constant password authentication.
I'm actually in the process of "kerberizing" this process courtesy of security/krb5 and a shell script, but that's a story for another time
 Work in progress so far.
  Work in progress so far.Hope this could be useful for some of you!
 
			     
 
		 
 
		 )
)

 
 
		 
						
					