RFC: Create a PatchAppliers group

Here is a draft of a proposal for the creation of a new usergroup. I'd really like feedback on this proposal, especially from the gods, who, obviously, would have the greatest stake in the change. Thanks in advance.

Make a special group, the members of which have the power to apply patches. No other divine powers are conferred. The intent, as currently envisioned, is that certain meritorious pmdevils will then be given patch application power. Membership in this group expires at the end of a certain period, to be determined by the gods on a case-by-case basis. It will allow the specially deputized pmdevil expeditiously to create and apply patches as necessary for some focused project — overhauling our xml generation capability, for example.

The steps necessary to create the group are:

Create a new usergroup, "patchappliers". (Only gods can create a group.)
Create an accessrule, "CanApplyPatch", defined as (in_gods||in_patchappliers). This could be done by appropriating (patching) an existing unused accessrule; or (possibly) via a request for new code node. Otherwise, the gods can simply create the new node.
Patch certain nodes (applypatch, patch edit page, and patch display page) to use this accessrule rather than isGod().

There is one complication: applypatch calls updateNode to do the work, and updateNode checks for authorization based on the type of the target node.
Possible solutions:

Add patchappliers to the updaters_user for all the patchable nodetypes. One potential problem stems from the fact that canUpdate/isApproved only check for user identity to one user/group (not including gods; they can always update any node*). If we find any patchable nodetype already having a value in its updaters_user field, we'll have a problem.
In applypatch, call updateNode() with a user value of -1, rather than $USER. This would work because isGod(-1) returns true. And since -1 is not a real user, there's no chance of the patch applier spoofing another user. (This would only affect the paper trail.)

These functions (updateNode, canUpdateNode, isApproved, isGod) all live in Everything/NodeBase.pm.

* The Everything code does provide a way to close this back door: a 'notgod' parameter. But this feature is not currently used in the PerlMonks codebase.

Acknowledgements

Much credit and thanks go to Petruchio, who had the original idea upon which this proposal is based, and who helped me elaborate it.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

Comment on RFC: Create a PatchAppliers group Select or Download Code

Replies are listed 'Best First'.
Re: RFC: Create a PatchAppliers group by Arunbear (Prior) on Feb 29, 2008 at 17:34 UTC
Having patch application power is effectively godhood - with it you could apply a patch that put yourself in the gods group, or one that deleted all nodes etc. The patch application mechanism cannot determine the safety or otherwise of a patch. So as far as I can see, patch application is best left to gods.	[reply]
Re^2: RFC: Create a PatchAppliers group (crub) by tye (Sage) on Mar 01, 2008 at 03:28 UTC
And there's the crux and there's the rub. Perhaps at least some grease to the process could be applied by having a group that is allowed to apply approved patches. Many who are paying attention may immediately conclude that this does no good. But the point would be that gods would be very quick to approve patches where it is obvious that no security problems are being introduced while it is almost never trivial to quickly apply a patch because one must pretty thoroughly vet the patch and then must test whether the application of it actually broke something. So, once a patch is approved, a path applier could, when they had the time, decide that the patch is worth applying, apply it, test the results, and then revert the patch if needed. So that delegates what is often a non-trivial amount of work away from gods. To complete some security details: Once a patch is approved, the author would no longer be allowed to modify the patch. When a patch applier applies an approved patch, the "current" patch is automatically approved. If there is no "current" patch, then the attempt to apply the patch is denied. Note that finding "the 'current' patch" involves scrolling through the most recently applied (few) patches until you find one that matches. Another possibility would be that modifying a patch unapproves it. But I would only allow that route for patches that have never been applied. Note that denying the ability to modify something probably needs to be implemented within the canUpdateNode() system. Several previous attempts to deny the ability to modify have turned out to have loop holes if they didn't cause canUpdateNode() to return a false value (due to some poor security-related choices in the Everything codebase). But our new accessRule feature should make this easy to implement. And the "editing removes approval" feature is another likely place for a loop hole to appear. It would probably be better to allow the author to unapprove a node of theirs if it has never been applied (which would then allow them to edit it as a separate step). On one minor technical point, there is no need to temporarily set $USER to -1. You just pass -1 (instead of $USER) to the updateNode() function. - tye	[reply]
Re^3: RFC: Create a PatchAppliers group (crub) by jdporter (Paladin) on Mar 04, 2008 at 13:25 UTC
... just pass -1 (instead of $USER) to the updateNode() function. Ah, duh. Thanks. I have updated the root node. The original text is left in an HTML comment.	[reply]


go ahead... be a heretic
	PerlMonks