This is not necessarily the current version of this TIP.This is not necessarily the current version of this TIP.
| TIP: | 220 |
| Title: | Escalate Privileges in VFS Close Callback |
| Version: | $Revision: 1.8 $ |
| Author: | Colin McCormack <colin at sharedtech dot dyndns dot org> |
| State: | Draft |
| Type: | Project |
| Tcl-Version: | 8.5 |
| Vote: | Pending |
| Created: | Sunday, 12 September 2004 |
This tip allows the creator and opener of a channel to cast away privileges and have them restored on close, to permit last-minute processing. It is sufficient to resolve a tclvfs bug, minimal, and safe.
Tclvfs has a bug [1004273] Can't read from channel in close callback [1] that is due in part to the core channel handler behaviour.
The problem is that the user has requested a read-only or write-only channel, but the tclvfs close process absolutely requires fuller access to the channel. For example: a user's write-only chan has to be read by close in order to be processed.
This can be modelled by the owner of a channel (in this case, the tclvfs code) opening it with minimal permissions, handing the channel to a user, then subsequently re-aquiring full possible channel permissions at the point where the channel needs to be closed - that is, immediately before the tclvfs close callback is invoked.
Escalation of privilege is controlled with the Tcl core, and is unavailable to extensions.
Privilege is only granted to the entity which opened the channel, because only that entity implements the close callback.
The creator/opener can't operate with any permissions it could not have obtained at creation/opening time, since they are granted by the OS and not Tcl.
Privilege escalation occurs only at a point immediately before the Tcl core is about to completely close the channel, so the privileges can't leak.
Immediately prior to invoking the VFS close callback, Tcl core should set permissions to the maximum possible.
This TIP was originally written to allow C code to modify permissions, but this makes the permissions system mean nothing, as a channel's permissions could then be freely modified in an ad hoc manner. The TIP now specifies a weaker modification that is still powerful enough to implemenent the desired channel semantics.
This document has been placed in the public domain.
This is not necessarily the current version of this TIP.