The more I think about this, the strong I come down on the side of it should 
all be local. Some of this is 'least surprise' stuff, some of it is system 
integrity, some of it is new security issues.

When I attach a USB device or hard drive, I expect it to be local. Sharing of 
local devices is almost never a default. The fact that someone attaches their 
sensitive data to an AFS device name shouldn't mean their data is suddenly 
shared. Least surprise applies, and security.

What do acls mean at that point? If I mount something on /afs/.../scs/dev/hda3 
and the acls for my account say it's publicly readable, can anyone in afsland 
mount and read my device? And lest someone asks "why would you do that", well, 
somebody will will come up with what looks like a perfectly good reason. If 
they can do it, somebody will do it. Consider the spammers who are happily 
making use of AFS storage that people permitted 'fs seta . anyser all' as a 
case in point.

How about when sombody has an esata drive. He wants it to be visible everywhere 
so he does 'mknod b 8 32 /afs/.../dev-mydrive'. It works just fine on his linux 
desktop where he's already got a /dev/sda and /dev/sdb, but pretty odd stuff 
will happen when he tries it on a machine that already has a /dev/sdc at minor 
node 32. And of course, he owns that file, so he should be able to read from it 
and write to it . . . even when it happens to be somebody else's disk.

No, for physical devices I think both 'least surprise' and 'unintended 
consequences' should mean the attached device is only visible on the host it's 
physically attached to.

Named sockets, named pipes, fifos, etc, are another interesting point. None of 
those are normally associated with a network service unless one takes extra 
steps to do so. Having those items be global because they happen to be in AFS . 
. . surprise! And let's again consider what ACLs mean.

I could go on, and in fact deleted a few paragraphs before sending. In summary, 
I don't think turning a global file space into a global service space should be 
done without a lot more thought and buyin from the the developers, the admins, 
and the end users.

For the moment, let's make devices/fifo/sockets that appear in AFS only be 
methods for naming local services and devices, not shared ones. If we want a 
global namespace to represent services, let's consider carefully if a 
filesystem is even the right way to do it.

Steve_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to