Hi, chohag wrote: > deraadt@ wrote: >> [email protected] wrote on Thu, Jul 04, 2019 at 01:35:36AM +0300:
>>> --- doas.1.~1.19.~ Sun Sep 4 18:20:37 2016 >>> +++ doas.1 Thu Jul 4 01:26:21 2019 >>> @@ -85,6 +85,12 @@ >>> Execute the command as >>> .Ar user . >>> The default is root. >>> +.Sh NOTE Absolutely not. That's a non-standard section, and we use non-standard sections only when there are are strong reasons, in particular very large amounts of text in the DESCRIPTION that need additional internal structure and subdivision. Note that the Linux man pages project - in sharp contrast to more widespread standards - endorses ".Sh NOTES" (note the plural) in its man-pages(7) manual page: https://man.openbsd.org/Linux-5.01/man-pages.7 # look for "NOTES" But that manual page is at odds with traditional and proven ways of writing Unix manual pages in lots of respects and not considered authoritative round here. NOTES sections are quite inacceptable. They usually arise when people fail to make up their minds how the content ought to be organized and instead jump around from one sub-topic to another and back again, and then put random afterthoughts into yet another section, NOTES. >>> +Although the kernel imposes no restrictions on the root user's ability >>> +to pose as any other user, >>> +.Nm >>> +will always require a password as per its configuration in order to >>> +keep unnecessary complications out of a critical security utility. No, there is no need to say that. As a general rule in Unix manual pages, if something isn't mentioned as a special case, then it isn't a special case. So from the the fact that nothing is said about root passwords, you can already conclude that doas(1) treats them the same as any other passwords. >> I don't see the point. >> >> If you get asked the question, and you know the answer, you answer it. >> Why is that not the end of the story? > When I used doas the other day to gain the rights of a user it asked > me for a password which I didn't expect, as I was root. Confirming > that there was no additional restriction somehow (I didn't think > there would be but it doesn't hurt) made me wonder why doas was > different. I couldn't find any acknowledgement of this state nor > at a look through related documentation any indication of whether > it was intentional or accidental. You are right that users may wonder about many different questions. But there are at least two kinds of questions that can in principle come in a infinite numbers: 1) Quirks and exceptions that could maybe be implemented but aren't. 2) Reasons for minor implementation choices. Explaining these two classes of points would be an open-ended task and would conflict with the goal of conciseness. So as a rule, we only describe what is implemented (but not what isn't), and also not why, unless that would matter for the user to use the tool correctly. It is obvious that in general, doas(1) needs authentication. The description of the -a option, https://man.openbsd.org/doas.1#a implicitely makes that clear, too, and https://man.openbsd.org/doas.conf.5#nopass already explains how to switch it off. So i think all the information is already there, at the places where it belongs. Yours, Ingo
