On Sunday 11 August 2002 09:14, Sven Kirmess wrote:
>Gene Heskett wrote:
>> I take it you unpacked, made, and installed amanda as root.
>> Generally speaking, thats a no-no.
>
>Yes I did. But that's only for a quick test... It should not be
> relevant

It's extremely revelant.

>who builds the code (only for security considerations). (Or am I
> wrong)?

Amanda is never run as root because amanda does its own suid when it 
needs to, which may well cause amanda to segfault when amanda finds 
out she is already root.

>If a segfault occoures the code is clear buggy. I segfault should
> never occour.

The coredump I don't know about.  Here it refuses to run amcheck as 
root, returning this:

[root@coyote root]# amcheck DailySet1
amcheck: running as user "root" instead of "amanda"
[root@coyote root]#

Now, lets see if I have a fresh core in /root...

No, that was a clean exit.  But then it was also properly built code 
from the last amanda-2.4.3b3-20020805 snapshot.

Please don't blame the code if its not properly built.  Doing so is 
unfair both to amanda, and to you, who feel like you have got to 
poormouth amanda when it doesn't work according to your ideas.  
Thats not only unfair, it also shows a lack of perusing the docs 
that come with her.  Please do so.

>
>I used these (and more) configure options
>--with-user=amanda --with-group=amanda

Amanda's group needs to be some group with disk access, which is why 
many of us choose to use the user 'disk' as amanda's group.  It 
seems like there is some sort of poetic license in that...  In any 
event, user amanda has no real rights inherited from group amanda.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.11% setiathome rank, not too shabby for a WV hillbilly