On Friday 04 August 2006 04:31, Stephen Carter wrote:
>>>> Gene Heskett <gene.heskett AT verizon DOT net> 08/02/06 12:09 PM >>>
>>
>>Then you don't have your amanda user in the correct group, amanda should
>> be a member of the group disk in your case.
>>
>>This walks and quacks like the incorrect installation duck, amanda
>> should be configured and built by the user amanda (or whoever is
>> actually going to run amanda, and NOT root) and this user should be a
>> member of the group that includes disk and backup.
>>
>>However, after amanda has been built by this user, then amanda must be
>>installed by root, thereby setting up all these permissions and setuids
>>automaticly.
>>
>I installed Amanda via rpm and it's been around in SuSE for a long time,
> so I would expect someone to have picked up this 'basic' problem and
> fixed it since SuSE 9.3 up to SLES 10 if it were an amanda compile /
> install issue (I tried this on SuSE 9.3, 10, 10.1, SLES9 & 10). The
> permissions are correct for the amanda user, and amanda's default group
> is the disk group.
>
>The problem is that the disk group has, by default, only read access to
> changer devices (/dev/sg*) in SuSE that are created dynamically during
> boot. The perms assigned are governed by rules in udev, which I pointed
> out.
>
>For what it's worth, all no changer tape devices (e.g. /dev/nst*) do give
> the disk group read and write perms by default so no problem there...
> it's only an issue if you are using a changer with SuSE (or CentOS
> apparently)
>
This is a frequent problem when using a 'packaged' version of amanda. The
rpm packagers in particular have demonstrated many times that they do not
understand how amanda treats security issues. Amanda's build gives it
enough perms to do the instant job each piece needs to do, and no more.
This is why, when potential users run into these sort of problems, that we
universally recommend that it be built from the tarball, following
amanda's instructions so that the amanda build and install can be done
correctly.
As for the udev permissions problem, I haven't used it yet (FC2 and RH7.3
boxes here) so I cannot advise on the exact fix, but I'm told there is
a .conf file that controls this, and that it can be edited to fix the
changer perms.
If the local build is not an option, then one should file a bugzilla entry
against the specific package(s) at Suse. I would include udev as the root
of the problem in this case.
>Stephen Carter
>Retrac Networking Limited
>www: http://www.retnet.co.uk
>Ph: +44 (0)7870 218 693
>Fax: +44 (0)870 7060 056
>CNA, CNE 6, CNS, CCNA, MCSE 2003
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
|
