On Sun, Oct 20, 2002 at 10:17:01AM +0200, Ivan Popov wrote:
> sorry if the question has been answered before, I am not aware of any
> answer.

I don't think I've seen it before.

> What is the authorization logic for cfs operations?

Pioctls are 'tagged' by the same credentials as regular filesystem
accesses. So for operations on objects they use the same rules as normal
ACL rights. For modifying operations on volumes, I believe you actually
need to be a member of the System:Administrators group. For more generic
commands, like hoard, you have to be a primary user (specified with the
primaryuser=<uid> option in venus.conf and if that doesn't exist whoever
is logged in /dev/console or /dev/tty0 (or was that tty1?)

But a whole lot are probably not adequately secured. Commands like cfs
disconnect and cfs reconnect really work at the wrong level (they filter
packets at the RPC2 layer). Cfs writedisconnect and writereconnect are
not persistent across volume state changes. Cfs strong and adaptive
really were introduced as hacks around the often failing bandwidth
estimation. strong also doesn't guarantee that the client will not start
logging operations in the CML, it just makes it a lot less likely.

> I am concerned about multiuser machines with users (un)consciously
> breaking things for other users.

That is still possible, best strategy right now is probably to have a
2x4 as a backup measure.

Jan