)]}'
{
  "commit": "e1f4a01157c08df1b0076595bfebe8564623505f",
  "tree": "23d82df45605a65d6eed0eb0cd0bef4127de0568",
  "parents": [
    "4b86a7be101f05f593fa2712646611cf6ed9ddd2"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Mon Jan 09 09:07:41 2017 -0500"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Mon Jan 09 19:01:40 2017 -0500"
  },
  "message": "Do not allow setting O_REMCLO with fcntl()\n\nThe rule with setting remove-on-close for a chan/FD is:\n\n\t\"You can only set REMCLO if you are allowed to remove.\"\n\nIt\u0027s up to the individual devices that support REMCLO to ensure this is\ntrue.  Devices from Plan 9 should already have done that, though who\nknows.  However, those old devices did not have fcntl()/dev.chan_ctl(),\nso they definitely would not have checked that angle.\n\nRegardless of old devices, allowing fcntl() to toggle REMCLO could still\nbe dangerous.  Consider a process that has a shared FD, but can\u0027t walk\nto the path of the chan.  Now it can potentially remove a file it\ncouldn\u0027t name.  I\u0027m not sure we want to allow that.\n\nFinally, the main aspect of the rule (which isn\u0027t enforced in this\npatch, but devices need to control) is that you can set REMCLO only if\nyou can remove.  If a process could set REMCLO without permission, then\nit could share the FD/chan with another process who does have\npermission, and then when that process closes the FD, it could trigger a\nremove.  This is a \u0027confused deputy\u0027 scenario.\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dd1d77a8882479c919708e87307d277c8360c1d2",
      "old_mode": 33188,
      "old_path": "kern/src/ns/sysfile.c",
      "new_id": "4c52336774063e2bf959dc2d251ad2e51d82ad6a",
      "new_mode": 33188,
      "new_path": "kern/src/ns/sysfile.c"
    }
  ]
}