[Acl-Devel] Bug/hole in getfacl format?

Ben Escoto bescoto@stanford.edu
Mon, 23 Jun 2003 10:22:27 -0700


--==_Exmh_-347123506P
Content-Type: text/plain; charset=us-ascii


Re my earlier post, I managed to patch my RH8.0 kernel after some
fiddling.  But now I'm trying to write a utility that can backup ACLs
and have a question about the format of the output of getfacl.

As you know, a record looks like this (made with version v2.2.7):

# file: foo
# owner: ben
# group: ben
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:root:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

# file: foo/file with
newline
# owner: ben
# group: ben
user::rwx
user:ben:---
group::r-x
mask::r-x
other::r-x

How are newlines quoted?  Note that the second entry is for a file
that has a newline in its name.  This causes an error when restoring:

~/work $ getfacl -R --skip-base . | setfacl --restore -
setfacl: (null): Invalid argument in line 32

I haven't tried it, but it also seems that a clever attacker could put
a fake acl record into the filename, potentially modifying the
permissions of an arbitrary file when setfacl --restore is run
(especially if '..' is allowed as a path component).

Whether or not this is a bug, how are strange characters (supposed to
be) handled by {set|get}facl?  Is it smart for a backup program to use
this format to store acls, or is there something I'm missing (format
likely to change, etc.).  Thanks for any information.


-- 
Ben Escoto

--==_Exmh_-347123506P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5CVS 01/04/2003

iD8DBQE+9zdR+owuOvknOnURAnoaAJ9Ev+V2jsWiuF44qSUwRPHO/iIyvACdGTTj
RDzmSEH2J/MhURW8x+gTN98=
=QOp9
-----END PGP SIGNATURE-----

--==_Exmh_-347123506P--