RE: tapelists permissions being changed...

[Chris Herrmann]

Ok...

Not using amadmin or amlabel...

yep - I meant the setuid bit :o) (told you the dumb stick had already been
through)


amdump.1 looks like:
-rw---1 operator root 8131 Feb  1 02:49 amdump.1

operator is the amanda user

taper looks like:
-rwxr-x---1 root disk32767 Aug 21 10:34 taper

amdump:
 -rwxr-x---1 root disk 3277 Aug 21 10:34 amdump

Digging through a working config we run here, and looking at the one in
question, I think it's a mix of screwy setuid bits, wrong user ownership of
files. So operator.disk now owns all of the files except for the ones that
are setuid root.

Will see how it goes tonight...

Thanks,

Chris

Re: tapelists permissions being changed...

[John R. Jackson]

and sure enough, if I check out the permissions:

-rw---1 root disk  104 Jan 30 01:05 tapelist

I can change the permissions, but they'll be reset after the next dump.

Which program writes to this file?  ...

Taper (amdump), amadmin and amlabel.

I'm assuming that I have a broken sticky
bit somewhere...

I assume you mean setuid (s), not sticky (t).

but I think I've been hit with the dumb stick this week -
can't find it for the life of me (I checked through the list of setuids that
you sent me last time John).

It's unlikely you're running amlabel, so that pretty much leave amadmin
or taper (from within amdump).  So, do you call amadmin as any part of
your dump sequence?  Do you call it as the Amanda user?

Are you positive you are running amdump as the Amanda user?  Who owns,
for instance, the amdump.1 file?  If it's root, too, then amdump is
being run by root.

Taper should most definitly **not** be setuid-root, so that could be
another problem.

Chris

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]