[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--