>>> - First, trash the idea of having a list of all possible cells in your
>>> filesystem. DNS should be the ultimate authority when it comes to
>>> cell information.
>
>OK, so what happens when I do opendir/readdir on /afs?
The same thing that happens now -- you scream and yell and frantically hit
Control-C while your application takes forever to stat a whole bunch of
filesystems across the Internet :-)
But seriously, this shouldn't affect the list of mountpoints in root.afs
at all - they're completely separate. Hell, you don't even need to have
a cell in CellServDB to create a mountpoint:
% ln -s #no.such.cell:no.volume. mountpoint
Okay, this is rather evil, but I'm trying to show that, AFAIK, the mount
points in root.afs are completely independent of CellServDB. If
they're not in CellServDB, you're get ENODEV when you try to access the
mount point, but in my "ideal world", this would trigger a DNS lookup,
and everything would hopefully work :-)
>You also haven't dealt with access control. Some sites have private
>cells they won't want to advertise. And some other sites might not
>want to make all cells available to their users. Having a fixed
>list of mountpoints in root.afs makes this sort of thing easier.
Having a fixed list of mount points in root.afs doesn't prevent a user
from using "fs mkm" in their own file space.
I would hope that people understand that not advertising their AFS cell
is the worst sort of security through obscurity :-) But for these people,
they could still use the CellServDB in my scheme; I did say I would
still keep the CellServDB around for older cells.
--Ken
