[2628] in SIPB-AFS-requests
Re: REQ: new volume for (non afs) backup info
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Feb 3 18:13:04 1997
From: mhpower@MIT.EDU
To: sit@MIT.EDU
Cc: sipb-afsreq@MIT.EDU, foley@MIT.EDU
In-Reply-To: "[2627] in SIPB-AFS-requests"
Date: Mon, 03 Feb 1997 18:12:44 EST
> ... The OSU system was also designed to have a single database
>for all tapes, which we were considering trying out.
This part does seem like a good idea. It might turn out to be
convenient to be able to access the database without logging into the
server machine, and presumably the acl could be set up to allow this.
>I was planning on creating/using AFS principals for the servers and
>having them get tokens, so that they can write to the tape DB.
Ok... but this still doesn't address the issue of whether the program
and script that gets the tokens should itself be run from AFS.
>If there's significant objection to having stuff stored in AFS, ...
I think it's very worthwhile to have the software stored in AFS, a new
volume for storing the software also seems like a really good idea,
the single tape database may have some big advantages (as I mentioned
above), but I still think the programs/scripts should be copied to
each machine's local disk. This is the approach we use for (I believe)
all of the other service.* volumes, and I think it'll probably be the
best approach for service.backup to work this way also.
Unless I'm misunderstanding something and it's not a workable solution
for the programs to be on local disk, but the database in AFS, I'll go
ahead and create the service.backup volume. Off hand, I'd guess that
all of the /usr/local/backup/db and /usr/local/backup/man directories
could be symlinks to the same AFS directories, but I haven't looked at
the new version of the software enough to know if that would work.
>Now, in any case, backups aren't done over encrypted links right? So
>there's probably enough information that gets sent over that would
>compromise security to some extent. I think that such a compromise
>would be more likely than an active AFS spoofing attack.
I'm not sure what you mean here. If we're sending information in the
clear that compromises security, we should immediately stop sending
that information. I don't think this has any real connection with
whether other attacks are more or less likely.
The first thing that comes to mind is the contents of /.klogin files.
I don't think it's especially important to not send them in the clear,
but I do think it can be effectively argued either way.
Matt
