How so, Coda has a pool of authenticated connections per user. But the
userspace cachemanager still needs to know which user performed the
operation in order to pick the right connection to send the message.
If user A opens a file and then user B writes/closes it, should it send
the write/close message over the authenticated connection of user B?
Ofcourse not, so we need to store the credentials of the opener with the
file.
This behaviour is the same for any filesystem that performs/requires
additional permission checking after a file is opened, i.e. probably all
network filesystems.
> The advantage of the model I described is that, with the exception of
> connection management, it works exactly like a normal filesystem with
> the exception of some totally inaccessible files due to server access
> denies.
Filedescriptors being used by processes with different user credentials
compared to the opener are more common than you might think. One common
example is stdout/stderr redirection with setuid apps in a shellscript,
another is due to fd passing through Unix domain sockets, or apps that
open files and then drop their priveledges. And it happens even more
with network sockets and pipes, although those possibly don't affect the
VFS (haven't checked if they use generic VFS paths, pipes probably do,
network sockets might).
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/