--On Friday, May 13, 2005 23:27:20 +0200 "Stefan G. Weichinger" <[EMAIL PROTECTED]> wrote:
> Hi, Jon, > > on Freitag, 13. Mai 2005 at 16:14 you wrote to amanda-users: > >>> Let me strongly suggest that a paragraph explaining that the base >>> directory in the DLE *must* be readable by amanda, so that it can >>> build the include file. > > JL> Absolutely. I think it is only needed for include, not for exclude. > > I thought this would be obvious ... every DLE has to be readable by > the amanda-user or, more detailled, the user, AMANDA has been > configured with (--with-user). That's not technically correct, I back up several DLEs that are not readable by the amanda user. Using a group such as disk or bin may give it access to the underlying device in order to run dump, but it doesn't give it access to all directories on that device when using tar. That is why many of the amanda binaries are suid root, so it can back it up. For example, I back up a DLE of /home/oracle using tar. The permissions on the directory are 700, and it is owned by oracle:dba and the amanda user can't see any of it (and proves it on every amcheck run complaining about not being able to read the amanda exclude file in there specified in the dumptype. However, since runtar is suid root, it can successfully read the exclude file and also backup the contents of that directory. Frank > > I quickly scanned this thread, AFAI can see there was no discussion of > the group-membership of the amanda-user (--with-group). A reason to > make the amanda-user member of a group like bin or disk is to provide > this user with the rights to read files it otherwise would not be > allowed to read. Just as a sidenote ... > > I don't know right now if there are differences between includes and > excludes when it comes to permissions, if there are, we should think > about how to handle them and if we should remove them. > > --- > > If you think the current behavior should get explained more > explicitly, please let me know where you would like to have this > information placed. > > -- > best regards, > Stefan > > Stefan G. Weichinger > mailto:[EMAIL PROTECTED] > > > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
