GNU bug report logs - #13226
24.3.50; set-file-acl on MS Windows shall check ACL string format

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 13226 <at> debbugs.gnu.org
Subject: bug#13226: 24.3.50; set-file-acl on MS Windows shall check ACL string format
Date: Wed, 19 Dec 2012 18:23:48 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Wed, 19 Dec 2012 13:24:45 +0100
> 
> File ACLs have different formats on MS Windows and POSIX systems:
> 
> --8<---------------cut here---------------start------------->8---
> (file-acl "~/.emacs")
> 
> "O:S-1-5-21-3955186872-1115707380-970145838-1000G:S-1-5-21-3955186872-1115707380-970145838-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-3955186872-1115707380-970145838-1000)"
> 
> (file-acl "/plink:albinus <at> ford:~/.emacs")
> 
> "user::rwx
> group::rwx
> other::r-x
> "
> --8<---------------cut here---------------end--------------->8---
> 
> If one copies a file with POSIX ACLs to MS Windows, `set-file-acl'
> raises an error. This shall be suppressed:

I assume that you want the error suppressed on MS-Windows, is that
right?  (The Subject of the report says "shall check the ACL string",
which the code already does; I guess you wanted to say "shall not" or
some such.)

If so, I don't think I agree, for several reasons.

First, this is in no way Windows specific.  In fact, when I added ACL
support for MS-Windows, I didn't change a single line in set-file-acl,
the code which tested for errors and signaled a file_error was already
there.  If I try this on GNU/Unix:

  (set-file-acl "foobar" "foo bar")

I get the same error:

  Debugger entered--Lisp error: (file-error "Converting ACL" "invalid argument" "/home/e/eliz/foobar")
    set-file-acl("foobar" "foo bar")

Which doesn't surprise me, since the code is not Windows specific, and
acl_from_text is documented to be able to produce EINVAL when its
string argument could not be converted to a valid ACL.

Second, I think it would be wrong to remove the error-checking code
from set-file-acl.  That function is a primitive, so signaling an
error when it cannot do its job is TRT; removing that would at best
take away a valuable diagnostics, and at worst disable your last line
of defense in some cases.  After all, whoever wants to set the file's
ACL to something does that for a reason; silently failing to do that
would give them no chance to take some corrective action.

OTOH, if an application, in this case Tramp, decides that it can
ignore these errors in some cases, it should catch the error and
ignore it.  It shouldn't pass the baton to primitives, IMO.  IOW, if
you want this suppressed, I think you should do it inside the Tramp
handler for copy-file.

Finally, I question the whole idea of copying ACLs between machines,
because they are inherently system-dependent, and even if both
machines run the same system, a user "foo" and a group "bar" on both
machines are likely to map to very different users and groups, at
least on Posix hosts.  (On Windows, the Security Identifiers, or SIDs,
of the user and the group that are recorded in the ACL are universal,
so this problem doesn't exist.)  So I'd actually suggest that we
explicitly refrain from doing this with remote files.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.