<snip>

> One major problem that I see, and one that I think would 
> cause me to not implement this on my systems, is security.  
> amrecover/amrestore are restricted to the root user for a 
> reason.  Ordinary users are not allowed access to some files. 
>  They are not even allowed to view the names of files in some 
> directories. Yet your scheme would allow users to browse the 
> backup indicies and even perhaps, recover files they should [not --
corrected in Jon's second email]
> have access to?

Hence why the interface would restrict them to their own home directory
and its' subfolders. Everything in a users' home directory is accessible
by them anyway, so it wouldn't matter. Softlinks couldn't be used to get
around this, because as far as I am aware, amrecover doesn't follow
softlinks. Even hardlinks turn out not to be a problem -- Users can only
create hardlinks to files that are visible to them in the first place
(eg i can hardlink to /etc/shadow), but then, even if I restore it, it
would be restored with the same ownership and permissions as previously,
and no extra access could be gained.

Of course, restricting them to their own home directory is easier said
than done. I do think it's possible, and I think the way to do this
would be to forbid ".." in the directory path, and to always maintain
the prefix you want. I'd appreciate it if someone could show how this
would result in a security problem (assume for a moment that I code the
interface correctly, and there are no exploits .... big assumption, I
know, but one that needs to be made for this to make sense)...

Even restoring files that are owned by someone else would not
neccessarily overwrite them -- they could all be restored within a
~/restored/ tree within the user's home directory. No real files (in
their homedir) get overwritten, etc, etc...

> As currently implemented (and I don't see this changing) the 
> only place the access rights to dirs and files is stored is 
> in the dumps themselves, on tape. So if you wanted to 
> properly restrict your user interface, you would have to read 
> all the tapes.  Even doing that, suppose there was a DLE of 
> /a/b/c/foo. All the info on the tape would be from "foo" 
> down.  How would you know if something in the path /a/b/c 
> might not restrict the users access to foo?

I don't propose giving them access to everything, only to their own home
directories. Anything more than this becomes orders of magnitude more
complex for the reasons you outline above.

> Your interface might restrict a user to recovering things 
> only under their home directory.  But surely in this vast 
> unix-land there are user home directory trees that have 
> inaccessible regions.

ie if there is a ~user/secret file or directory tree, owned by (say)
root, and with permissions 700, such that the user can't read the
contents of the file or list the directory...

OK... If it's a file, nothing has changed. The user can see the file,
but not the contents. amrecover (or rather, the web interface to it)
would give them nothing more than this.

If it's a directory, and the contents of the directory are intended to
remain secret, then yes, this concept would affect that secrecy. The
user would be able to list the files in the directory, and restore them
(to ~/home/restored/, not over the top of the existing files). However,
when they return to the filesystem, they still can't see the directory
(yes, they know what's in there), and they can't view any contents of
files.

I see no simple way around this problem of allowing people to list the
contents of secret directories within their home directories. However, I
also don't see much likelyhood of that being a common setup anywhere. I
can't really imagine why this would be the case. Certainly, it's not the
case on any of the systems I administer, and would not pose a problem on
the system I plan to implement this on. I think this would have to be a
stated limitation of the interface, and people who had that requirement
would be advised not to implement this (hypothetical) system.

I think I see the security issue you are drawing attention to, but I
also think that for the most part, it wouldn't actually matter, and if
it does, the sysadmin would know (I assume...), and would choose not to
implement it. If my understanding is correct, it certainly poses no
threat to my particular system.

Cheers, and thanks.

rr


-- 
Richard Russell
Yellow Goanna P/L
m: +61 412 827 805
e: richard AT yellowgoanna DOT com
w: http://www.yellowgoanna.com