> We can do more than drop id, we can use the same minimal pledge
> that will be enforced later since root doesn't need to call
> auth_userokay().
>
> In fact, root doesn't need proc or exec. Is this going too far?
That's a nice observation. Your diff looks fine to me as it is.
In the patch be
On Tue, 17 May 2016 17:03:06 +0200, Theo Buehler wrote:
> > @@ -151,6 +157,11 @@ main(int argc, char **argv)
> > } else if (strcmp(pp->pw_name, me) != 0 && getuid() != 0) {
> > /* Only root can change other's S/Keys. */
> > errx(1, "Permission de
Looks good to me.
> @@ -151,6 +157,11 @@ main(int argc, char **argv)
> } else if (strcmp(pp->pw_name, me) != 0 && getuid() != 0) {
> /* Only root can change other's S/Keys. */
> errx(1, "Permission denied.");
> + } else {
> + /
On Tue, 17 May 2016 16:21:47 +0200, Theo Buehler wrote:
> I agree with your diagnosis. skeyinit tries to fchown the file to the
> target user and gets EPERM since it is running with pledge.
>
> Here's a patch that disables pledge for skeyinit if it is run as root
> and there is a target user spec
On Tue, May 17, 2016 at 08:52:28AM -0600, Todd C. Miller wrote:
> On Tue, 17 May 2016 16:21:47 +0200, Theo Buehler wrote:
>
> > I agree with your diagnosis. skeyinit tries to fchown the file to the
> > target user and gets EPERM since it is running with pledge.
> >
> > Here's a patch that disable
On Tue, May 17, 2016 at 01:45:18PM +0200, Silamael wrote:
> Since OpenBSD 5.9 it's no longer possible to run skeyinit for another
> user while being root:
>
> root@testpc:~# skeyinit -md5 admin
> [Adding admin with md5]
> skeyinit: can't set owner/mode for admin: Operation not permitted
>
> As fa
Hi there,
Since OpenBSD 5.9 it's no longer possible to run skeyinit for another
user while being root:
root@testpc:~# skeyinit -md5 admin
[Adding admin with md5]
skeyinit: can't set owner/mode for admin: Operation not permitted
As far as I unterstand the check in pledge_chown() in kern_pledge
