Conference smurf::dec_mls_plus

	If this is MLS 4.0 rev 40,
	mltape should not even be creating the file on the server
	system unless ALL ACL's can be set. So if a user or group
	does not exist on the server system, mltape will output a 
	Can't set ACL error message and the file will not be restored.
	
	My questions are, did mltape restore this file with no error
	message?
	Is it possible to see the lsacl on the failing and nonfailing
	access files?

				Mark		
	
>    We occasionaly get files from other MLS+ systems via mltape backup tapes.
> These systems have the same users defined (passwd file, group file, etc.).
> They also have a few other additional users defined that we don't. Sometimes
> the files have ACL entries for user indexes that are not defined on our
> system.
[Posted by WWW Notes gateway]

    Patrick AFB is running V3.1A -- I believe they have a support contract,
    so they should have been sent V4.0A upgrade kit -- perhaps Janet can
    check with them sometime whether they received it or not (and maybe
    even if they intend to upgrade sometime...)

    
	Check me on this:   

	I interpreted Sam's description of the problem as follows:

	[  System A    ]          [      System B          ]
	[ "Our system" ]<-------->[ "Machine Serving Disk" ]
					   |
					( disk )

	System A is importing disk from System B.  Someone got
	an mltape archive on tape and loaded it on System B's disk
	by running mltape on System B.

	Now, when we are talking about UIDs and GIDs, if the
	UID or GID on an NFS mounted file system does not
	exist in the importing system's passwd or group file*,
	you will see the UID or GID's numeric value, but not
	it's translation if you do an ls -l.

	But evidently, if the file has an ACL on it, and the
	UID or GID used in the ACL is not being recognized.

	I tried to reproduce this, but could not.  However, I didn't put 
	mltape into the loop, I just created a file in a file system with an 
	ACL that used a group and user ID that did not exist on the system 
	to which I exported that file system.  A user did not have
	a problem seeing the ACL - the UID was the UID value, and
	the GID was "guest" (weird -- in an ls -l the GID is the GID
	value).

	However, I believe Patrick is using YP and I didn't not
	try it having a local uid/gid on the exporting system not
	on the importing system, and although I wouldn't expect it
	to be different, it might.
    

	I would bet that the system they are getting IO errors
from while trying to access the file does not have entries in the
NIS server which match the ACL. They could verify this by doing
the following: 
1) An lsacl on the file on the server system. This will show which
	specific users and groups have ACLs set.
2) On the system getting IO errors they can ypcat for those users
	and groups using, ypcat passwd | grep username and
	ypcat group | grep groupname
	
	Even on V3.1A patch level 10, V3.1 29-1, mltape
returns "Can't set ACL" errors when the user or group name is 
missing. An mltape record has the ACL's listed by name not
UID or GID so when mltape was run on system B the files 
should not have been restored.
	In the record below, if the user rscsrjd or the 
group rscssey were missing, mltape would not restore the file.
	
	An mltape record looks like this:
100770 99       1536 Jan 10 08:28:10 1997 rscssey/NOS/PF/CYBER/VU
        SLABEL: UNCLASSIFIED
        ILABEL: UNCLASSIFIED
        PACL:    user::rwx
mask::rwx
user:rscsrjd:r--

group::rwx
group:rscssey:rw-

other::---



[Posted by WWW Notes gateway]

    A discussion with Mark came up with the scenario that perhaps they are
    running NIS and when the lookup fails on the UID or GID, it returns an
    error instead of using using the UID or GID value it asked to have
    looked up, as it does when it does a regular non-NIS lookup.

    Update -
    
    The customer is using NIS (and is currently having issues with it that
    I'm looking into now...)
    
    Thanks,
    janet