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
