wiztool: shutdown ungated while reboot requires FULL_ACCESS

[ChristopherA]

In src/kernel/lib/wiztool.c, cmd_reboot() checks access(owner, "/", FULL_ACCESS) before acting, but cmd_shutdown() performs shutdown() with no access check (lines ~2254-2285). Any user with wiztool access can halt the system, while rebooting -- arguably the less destructive operation, since it snapshots first -- is gated.

Is the asymmetry intentional? If not, gating cmd_shutdown the same way as cmd_reboot seems consistent.

[dworkin]

The access check is performed in shutdown(), which is called by cmd_shutdown(). cmd_reboot() needs its own access check because it directly calls kfuns.

[ChristopherA]

Thanks — I think we're pointing at two different checks, and I should have been clearer about which one I meant.

The check reached from cmd_shutdown() is on the object, not on the user. auto.c:704 tests creator != "System", and creator comes from the object's own name: auto.c:40 maps anything matching /kernel/%*s to "System". The wiztool is /kernel/obj/wiztool.c, so its creator is "System" for every clone, and that condition cannot be true when cmd_shutdown() calls through at wiztool.c:2264. It's a tier check keeping /usr/ code out of the kfun, and it does that correctly.

cmd_reboot() tests something else: access(owner, "/", FULL_ACCESS) at wiztool.c:2278, where owner is the user the wiztool clone belongs to, set from TLS at clone time (auto.c:137, versus auto.c:145 for a non-clone). That's a per-user rights check, and it's the one I meant by "access gate".

From the operator's side the two commands therefore differ. kernel/obj/wiztool.c:97-99 dispatches shutdown and reboot through the same call_other(this_object(), "cmd_" + str, user, str, arg) with no gating, after which a user whose access does not include FULL_ACCESS on / gets Permission denied. from reboot and halts the system with shutdown.

What makes me think this isn't just my misreading: access(owner, "/", FULL_ACCESS) appears at sixteen call sites in wiztool.c, across 27 cmd_ functions — code, ed, grant, quota, rsrc and the rest. If holding a wiztool already implied full authority, all sixteen would be dead code. They aren't, which suggests possession was deliberately treated as insufficient on its own, and shutdown stops the system just as surely as reboot does, minus the snapshot.

Entirely possible this is intended and I've drawn the line in the wrong place — if a wiztool is meant to be a full-authority instrument for lifecycle commands specifically, then the reading is that cmd_reboot()'s check is the outlier rather than cmd_shutdown()'s absence. Either way I wanted the creator versus owner distinction on the record, since it decides which of the two is the anomaly.

(Verified against 1c72847.)

[dworkin]

I believe that you have missed that shutdown() is redefined in /kernel/lib/wiztool. The redefined function performs the same owner-based access check as cmd_reboot(). It does so because /kernel/lib/wiztool is meant to be inherited; it has to override lower-level functions and enforce wiztool-level access restrictions on them, not only on the commands.

With the owner-based access check in wiztool::shutdown(), cmd_shutdown() does not need its own access check. cmd_reboot() does need one, because there is no reboot() function where this could have been done.