tree 23d82df45605a65d6eed0eb0cd0bef4127de0568
parent 4b86a7be101f05f593fa2712646611cf6ed9ddd2
author Barret Rhoden <brho@cs.berkeley.edu> 1483970861 -0500
committer Barret Rhoden <brho@cs.berkeley.edu> 1484006500 -0500

Do not allow setting O_REMCLO with fcntl()

The rule with setting remove-on-close for a chan/FD is:

	"You can only set REMCLO if you are allowed to remove."

It's up to the individual devices that support REMCLO to ensure this is
true.  Devices from Plan 9 should already have done that, though who
knows.  However, those old devices did not have fcntl()/dev.chan_ctl(),
so they definitely would not have checked that angle.

Regardless of old devices, allowing fcntl() to toggle REMCLO could still
be dangerous.  Consider a process that has a shared FD, but can't walk
to the path of the chan.  Now it can potentially remove a file it
couldn't name.  I'm not sure we want to allow that.

Finally, the main aspect of the rule (which isn't enforced in this
patch, but devices need to control) is that you can set REMCLO only if
you can remove.  If a process could set REMCLO without permission, then
it could share the FD/chan with another process who does have
permission, and then when that process closes the FD, it could trigger a
remove.  This is a 'confused deputy' scenario.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>