Ted Unangst writes:
> Ted Unangst wrote:
> > I think this is not the right note, but after some review I just realized we
> > don't ever say that a password is required. It's merely hinted at in various
> > options. I'll make a note of that.
>
> Just a simple sentence, but I think it makes
Ted Unangst wrote:
> I think this is not the right note, but after some review I just realized we
> don't ever say that a password is required. It's merely hinted at in various
> options. I'll make a note of that.
Just a simple sentence, but I think it makes explicit the behavior.
Index: doas.1
cho...@jtan.com wrote:
> Ingo Schwarze writes:
> > I see nothing wrong with it. It is easier to describe in the manual
>
> Indeed I was not suggesting that there was something wrong; being asked for a
> password when doing something which root could implicitly do simply confused
> me for a
Hi,
chohag wrote:
> deraadt@ wrote:
>> cho...@jtan.com 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.
Theo de Raadt writes:
> 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.
Ingo Schwarze writes:
> I see nothing wrong with it. It is easier to describe in the manual
Indeed I was not suggesting that there was something wrong; being asked for a
password when doing something which root could implicitly do simply confused me
for a moment which prompted figuring out
Hi Matthew,
cho...@jtan.com wrote on Tue, Jul 02, 2019 at 11:43:13AM +0300:
> This isn't a bug per se,
Indeed not a bug.
> more of an incongruity in how security-centric tools work wrt root,
Sure. Different tools are different. In particular, in addition
to major differences in behaviour
This isn't a bug per se, more of an incongruity in how security-centric tools
work wrt root, specifically doas and chroot/su/other:
joe@drogo$ doas -s
drogo# doas -u chohag -s
doas (root@drogo) password:
doas: Authorization failed
drogo# chroot -u chohag /
drogo$ ^D
drogo# su -l
