Thanks to everyone that responded to my
ACL question concerning backups, and ACLs
in general. As a nubie to Tru64, I'm glad to
see there's a good community out here to help
with these issues.
Cheers!
Marty
>-----Original Message-----
>From: Saletta, Marty, M.
>Sent: Tuesday, November 21, 2000 4:19 PM
>To: 'tru64-unix-managers_at_ornl.gov'
>Subject: ACL: backup issues?
>
> We're looking into the access control list (ACL) feature
>of Tru64, and we've got a question. When a file is set up
>with ACLs by the user or root, and that file is backed up
>to tape, does the ACL information remain intact upon
>restore?
*** From Dr. Tom Blinn:
The file system specific backup/restore utilities (dump/restore for
UFS, vdump/vrestore for UFS or AdvFS) are SUPPOSED to save ACLs as
you do a dump (to any target media) and restore them if you ever do
the restore. The more generic utilities (tar/pax/cpio) do not do
this, to the best of my knowledge, but I could be mistaken; they are
targeted toward compatibility across different vendors, and ACLs are
not necessarily compatible or transferrable.
However, you need to verify that these things work; in some releases
some of the ACL backup/restore functionality has been broken in some
of the utilities, and you would probably not find this out until you
tried to do a restore operation. Setting ACLs on both directories
and files and then doing a test transfer (even just to another part
of the same file system) would be a good test of this. If it isn't
working, it's a bug, and there may be a patch, but you would need to
also verify the patched version of the utility. (You SHOULD be able
to trust us on this stuff, but in my experience, we sometimes get it
wrong because we don't use the ACLs on our production systems and as
far as I can tell, we don't have good regression testing in this part
of the product.)
*** Ed Bolson reported that Networker saves the ACL information
*** From Ann Majeske:
The ACLs are stored in the extended attributes of the file
(see man proplist(4)). Extended File Attributes are a Compaq
specific extension, so you should not expect any 3rd party
products to save and restore the ACLs. As for Compaq Commands
and Utilities:
- As far as I know, the dump(8) and restore(8) commands will
save and restore ACLs accurately.
- I'm not so sure about vdump(8) and vrestore(8).
- There were some bugs in how pax(1) and tar(1) restored ACLs,
but I think they were mostly that they restored the ACLs from
the archive even if you didn't want to. These bugs were fixed
in V5.0A. When using tar you should use the "-p" option,
when using pax you should use the "-p p" or "-p e" to make
sure the ACLs are preserved from the archive. The default
is to not preserve the ACLs.
- There was a bug in how cp(1) interacted with ACLs. This bug
was fixed in V5.0. Whenever you copy a file with an ACL, make
sure to use "cp -p" to preserve the ACL from the source file,
the default is to not preserve the ACL.
- Consider putting Default ACLs on your directories so that if
an ACL "accidentally" doesn't get restored, that you have an
ACL anyway.
Looking at the above, it would be advisable for you to be running
at least V5.0A to use ACLs. If not, you should try contacting
Compaq support to see if you can get patches for the bugs.
*** From Claude Scarpelli:
The answer depends on the program used to do the backup : Tru64
versions of tar, cpio (not tested) and vdump/vrestore do support ACL,
and Networker (version 5) as well.
Gnutar does not support ACL.
> I guess I'm trying to puzzle out just where the ACL
>database is maintained- is it a file on the filesystem
>or does it become part of the file itself?
*** From Dr. Tom Blinn:
The ACLs are part of the file system metadata for file systems that
support ACLs (not every file system type does; it doesn't make sense
in some cases, in other cases it's not implemented by some other
system, e.g., some NFS hosts don't support ACLs). They are not in a
separate file, nor are they embedded in the file itself. Think of
them as being tied to the inode, just as other file attributes are
tied (ownership and traditional UNIX protection).
> Does anyone have any opinions about ACLs in general?
>Do they really work as advertised? So far in our testing they
>seem to be fine.
*** From Ann Majeske:
One comment that I'd like to make is that currently use of ACLs
requires active participation on the part of the file owner to
make sure that the file stays protected. With UNIX programs
that modify files it is very common to:
- make a copy of the file
- modify the copy
- delete the original
- rename the copy to the original name
When this happens you will lose the ACL unless the program knows
enough to copy the extended attributes as well as the file data
or you have a Default Access ACL on the parent directory.
Since extended attributes are a Compaq specific extension it is
likely that any program you use to modify your file won't
properly maintain the ACL.
Another possibility to look out for is if you give anyone else
write permission to the directory containing the file. If someone
has write access to the directory they can delete the file and
create their own version (with their own ACL) even if the ACL
refuses them permission to the file. This is because the ability
to delete the file is determined by their ability to write to the
directory, not the file itself. So, make sure your directories are
protected by ACLs as well as your files.
Taken altogether this means that the owner of the file should:
- Double check to make sure that the ACL on his file is intact
after he makes any kind of modification. One way to do this
would be to make a copy of the file, make the modification to
the copy, then copy the copy back on top of the original (using
cp without the -p option so that the file keeps it's original ACL).
- Make sure that no-one else has write permission to his directory.
- Consider putting a Default Access ACL on the directory. Then, any
file created in that directory will get an ACL automatically.
So, in general, ACLs work, but they're not something you can just
"set and forget". Using Default ACLs to protect whole directories
would be an easier setup than trying to maintain different ACLs
on a bunch of individual files.
*** From Tobias Burnus:
We use them in an Alpha/FreeBSD pool at our department, using a
automount demone (AM-utils) and proplists. If other clients besides the
Tru64/OSF1 ones, make sure you use NFS version 3. Using NFS2 the client
looks at the unix file attributes, with NFS3 it asks the server.
NFS 4 will support ACL, so when all clients and server speak this
protocol you will be able to set/getacl on all computers.
*** From Claude Scarpelli:
The main problem we saw with ACL is that they are almost invisible !
Only getacl(1) show the file's ACL (Solaris ls(1) displays a '+' sign
after the mod bits when a file has an ACL).
We are using ACL in order to protect access to project's
subdirectories: people are granted (or not) to access a project
subdirectory according to the ACL set for this subdirectory. We have
too many projects, so multiple GID are not a solution. That's the only
usage. We don't use any of the default ACL.
ACL, in our context, works well with NFSv3, which Solaris does
support. It means that Solaris NFSv3 client follow the access rules,
even though Solaris has no knowledge of Tru64's ACL (Solaris have ACL
too, but they don't seem to be interoperable - see getfacl() in your
favorite Solaris system). Actually, it works because of NFS v3. Bottom
line is : NFSv3 is required. man 4 proplist provides detailed
information on NFSv2 behaviour in presence of ACL.
Copies program (Tru64 cp, tar....) that want to restore file's ACL
must read and write the ACL, which are not very fast operations in NFS
(and requires the proplist daemon).
Marty Saletta, System Administrator
Celera Genomics Corporation
marty.saletta_at_celera.com
Received on Mon Nov 27 2000 - 19:58:10 NZDT