It was a quiet weekend -- Glad to see this list popping again.

A set-up problem that I sent last week is still with me, i.e amcheck
reports "permission denied" for the disks in disklist (client and server
are the same). Since last posting, I've tried changing disklist to specify local disk
access:

raleigh.cpt.afip.org /gilmore nocomp-root -1 local
raleigh.cpt.afip.org /dev/dsk/dks0d4s3 nocomp-root -1 local

I also tried recompile/reinstall (both as root) with

FORCE_USERID=no

set in config.site file.

Neither trick fixed the problem, i.e:

raleigh 37% amcheck -c config_orig

Amanda Backup Client Hosts Check
--------------------------------
ERROR: raleigh.cpt.afip.org: [could not access /dev/rdsk/dks0d4s3 (/dev/dsk/dks0d4s3): 
Permission denied]
ERROR: raleigh.cpt.afip.org: [could not access /dev/rdsk/dks0d4s2 (/gilmore): 
Permission denied]
Client check: 1 host checked in 20.043 seconds, 2 problems found

(brought to you by Amanda 2.4.2p2)
raleigh 38%

I see no clear evidence that amandad is the problem -- there have been up
to seven instances of it listed in a single ps -elf request, and there is
no "server timeout" notice when I run both client and server amcheck.

This still smells like an Irix suid problem, but I don't know how to get
at it. The only suid-oriented tweak we've made to the OS was in fixing
a well known security hole (-s bit set on file suid_exec) that shipped
with previous versions of Irix. Current version (6.5) does not even have
that file.

Still hoping that someone can post the solution, or maybe point to info on
how Amanda uses suid so I can track it down more easily. Thanks.

R. Becker


On Fri, 24 May 2002, Robert L. Becker wrote:

> I checked the permissions at the level of the mount point and the block
> device file. Indeed, the block device was more restricted (600) than the
> mount point (755). So, as a test, I set permissions at both entries to 777
> and retried amcheck. No effect. The client check still flags an error:
>
> Amanda Backup Client Hosts Check
> --------------------------------
> ERROR: raleigh: [could not access /dev/rdsk/dks0d4s3 (/whitmore):
> Permission denied]
>
>
> I wonder if this is a remote host (any client) access problem, though I've
> tried to cover this in ~amanda/.amandahosts:
>
> raleigh 10% cat ~amanda/.amandahosts
> raleigh.cpt.afip.org amanda
> raleigh amanda
>
> I also wonder if current absence of an amandad process (according to ps
> -elf) is a clue -- though I have made the recommended entries in
> /etc/services and /etc/inetd.conf files and saw that as many as two
> amandad processes showed in the ps listing when I stopped/restarted the
> network after editing those files. Looking for suggestions still...
>
> R. Becker
>
>
> On Fri, 24 May 2002, fil krohnengold wrote:
>
> > At Fri, 24 May 2002 14:44:04 EDT, [EMAIL PROTECTED] wrote...
> > : Here's a permissions problem that I don't understand, reported by
> > : amcheck. Client and server are the same host (raleigh):
> > :
> > [...]
> > : Amanda Backup Client Hosts Check
> > : --------------------------------
> > : ERROR: raleigh: [could not access /dev/rdsk/dks0d4s3 (/whitmore):
> > : Permission denied]
> > [...]
> > :
> > : Amanda is installed as user amanda in group sys. Far as I can tell, the
> > : file systems should be ok for amanda to read. For example:
> > :
> > : raleigh 2% ls -l / | grep whit
> > : drwxr-xr-x    3 root     sys             24 May 15 08:02 whitmore
> >
> > Significant permissions are set on the raw disk device - under
> > solaris it looks like this (excuse the long lines):
> >
> >   blinky:~> df -k .
> >   Filesystem            kbytes    used   avail capacity  Mounted on
> >   /dev/dsk/c0t0d0s4    6705645 1676432 4962157    26%    /local
> >   blinky:~> ls -l /dev/dsk/c0t0d0s4
> >   lrwxrwxrwx   1 root     root          46 Dec 30 16:41 /dev/dsk/c0t0d0s4 -> 
>../../devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e
> >   blinky:~> ls -l /devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e
> >   brw-rw----   1 root     sys       65,  4 Jan  9 19:03 
>/devices/pci@1f,0/pci@1,1/ide@3/dad@0,0:e
> >
> > Check to see what the permissions are on /dev/rdsk/dks0d4s3,
> > etc..  That may be your problem.
> >
> > -fil
> > --
> > fil krohnengold
> > systems administrator - IT
> > american museum of natural history
> > [EMAIL PROTECTED]
> >
>
> Robert L. Becker, Jr.
> Col, USAF, MC
> Department of Cellular Pathology
> Armed Forces Institute of Pathology
> Washington, DC 20306-6000
> 301-319-0300
>
>

Robert L. Becker, Jr.
Col, USAF, MC
Department of Cellular Pathology
Armed Forces Institute of Pathology
Washington, DC 20306-6000
301-319-0300


Reply via email to