Amanda-Users

permissions bugs on holdingdisk run directory and on tapelist?

2006-09-24 22:38:07
Subject: permissions bugs on holdingdisk run directory and on tapelist?
From: Steve Newcomb <srn AT coolheads DOT com>
To: Kevin Till <kevin.till AT zmanda DOT com>
Date: 24 Sep 2006 21:30:20 -0400
Well, we're getting there, but 2.5.1 still doesn't quite work for me,
this time because of what looks like an Amanda permissions bug.
The only work-around I can see is to have Amanda be super-user.
Here's what happens...

Nothing gets written to the holdingdisk.  Amdump complains that
it's not writeable.  Amstatus complains that the dumpers are all
idle because there's no disk space.

Well, the holdingdisk is perfectly writeable.  And amdump creates a
directory in it whose name is a timestamp.  The permissions on that
directory are 700 (drwx------), with "root" as owner and "disk" as
group.  The amanda user is supposed to be "amanda".  Both root and
amanda are in group "disk".  So evidently the dumpers can't write to
the spool directory (named with a timestamp) because they are not
running as superuser, and it doesn't matter whether the dumpers are in
group disk because there are no group permissions on that directory.

To make things even more bizarre, the timestamp directory is only
there for a minute or two, and then it is deleted, probably because
there's nothing in it to flush.  This is extremely confusing, because
when the whole misadventure is over, unless you noticed the transient
existence of this almost permissionless directory, Amanda leaves you
with the following misinformation:

  * amstatus says there was no disk space.  But there's plenty.

  * the emailed report from Amanda says, for example:

     bruno.coolheads.com / lev 0 FAILED [can't dump required holdingdisk]

     ...but there's no reason why the holdingdisk can't be written
     upon by both root and amanda, and any other member of group disk.

#######################################################

I think the above problem is a critical problem.  The following
problem is not critical, but it's similar and it's quite annoying:

Amcheck complains that tapelist isn't writeable.  And it's true: it's
not writeable, and that's because Amanda made it that way during the
previous run.  Then, when you change the permissions on tapelist,
amcheck can see it, and that's when amcheck can start to tell you
whether you've got the right tapes in the right drives.  Otherwise,
amcheck thinks that your tapes are very nice Amanda-labelled tapes,
but it knows nothing about them.  But after the next run, amcheck will
be broken again for the same reason.

#######################################################

Thanks, guys, for any advice or help.  I'd rather not make the amanda
user the super user, but what the hey, she has to SUID to root
anyway...  Is that the way you're supposed to run Amanda?  I never
have done so before.


-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)

srn AT coolheads DOT com
http://www.coolheads.com

direct: +1 540 951 9773
main:   +1 540 951 9774
fax:    +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA


(Confidential to all US government personnel to whom this private
letter is not addressed and who are reading it in the absence of a
specific search warrant: You are violating the law and you are
co-conspiring to subvert the Constitution that you are sworn to
defend.  You can either refuse to commit this crime, or you can expect
to suffer criminal sanctions in the future, when the current
administration of the United States of America has been replaced by
one that respects the rule of law.  I do not envy you for having to
make this difficult choice, but I urge you to make it wisely.)




<Prev in Thread] Current Thread [Next in Thread>