Why Unix setuid is incompatible with real network filesystems
One of the drawbacks of real network filesystems like AFS is that they don't support setuid. This isn't a feature that they've neglected to implement; it's a fundamental incompatibility.
The reason is ultimately simple: in a real network filesystem, the server doesn't trust the end nodes, and in particular it doesn't trust the end nodes not to lie to it. If an end node says 'the user X is doing this', the server must say 'prove it; show me that the user trusts you'. This trust is demonstrated through shared secrets; the user has a secret shared with the server, and the end node shows that it has the user's trust by showing it also knows the secret. And the whole problem is that setuid has no user there to share the secret with the end node.
This might seem unimportant, except that Unix uses the general idea
of setuid for a lot more than just setuid programs. If you don't have
setuid, you don't have anything that runs a program on behalf of the
user: .forward
s, cron entries, web server CGI scripts, and often
even long-running daemons. You basically lose everything that wants to
operate unattended, and it turns out that this is a reasonably large
category of interesting stuff.
There are ways around this, but they are fundamentally hacks. They involve either the overall system trusting some carefully selected and authenticated end node to speak on behalf of users, or you outright giving your key to some end node that you trust. (Sometimes you are lucky and the system will allow you to create restricted sub-accounts, so that compromising the daemon or the system or whatever will not give access to your entire account.)
(There is a limited third way, which is subsystems giving you the ability to run limited programs or instructions inside themselves. It is probably not an accident that CMU's Andrew Project invented both AFS and Flames, an early in-server email classification program.)
|
|