actually touches the ACLs for newly created files and directories. smbd
only seems to manipulate ACLs when they're changed from a windows client.
3. The "inherit acls" config option does not fix this problem,
which is not surprising since that's not what the option is intended to do.
------_=_NextPart_001_01C260B4.8812FA00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html;
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version
5.5.2653.12">
<TITLE>ACLs and DACLs not propagated to owner of
file/directory</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hello,</FONT>
<BR>
<FONT SIZE=3D2>I've submitted the following to the bug tracking
system, but thought I might find some other answers here.</FONT>
<BR>
<FONT SIZE=3D2>It appears that there is a bug in the ACL code that
prevents a ACL or DACL from being applied to directory if the user associated
with that ACL is the owner of the file.</FONT></P>
<P>
<FONT SIZE=3D2>Consider the following directory structure</FONT>
</P>
<P><FONT SIZE=3D2>top->|</FONT>
<BR><FONT SIZE=3D2>
|->a|</FONT>
<BR><FONT SIZE=3D2>
|->1</FONT>
<BR><FONT SIZE=3D2>
| |->2</FONT>
<BR><FONT SIZE=3D2>
|</FONT>
<BR><FONT SIZE=3D2>
|->b|</FONT>
<BR><FONT
SIZE=3D2>
|->3</FONT>
<BR><FONT
SIZE=3D2>
|->4</FONT>
</P>
<P>
<FONT SIZE=3D2>All directories are owned by root/sys and contain
read/write/execute ACLs for tom, dick, harry, and bob. A user listed
in admin users for the share chooses adds an ACL for tim (rwx) from win2k to the
top directory. All is well at this point. ACLs and DACLs for
each user are applied to each folder.</FONT></P>
<P>
<FONT SIZE=3D2>Now tom (who does not have admin rights to the share)
creates a directory alpha</FONT>
<BR><FONT SIZE=3D2>under top->a->1 . He is
the owner, and the directory contains all of the ACLs from 1, including the
default ACL default:user:tom:rwx. The acl user:tom:rwx also exists, as
does user::rwx, the representation of the unix permissions. So far so
good.</FONT></P>
<P>
<FONT SIZE=3D2>Now the same admin user with root privs accesses the share
from win2k and recursively adds an acl for jane to the top level, giving her
read/write/execute. This is when things start to fall apart.
The new directory alpha LOSES the ACL user:tom:rwx and the default ACL
default:user:tom:rwx. If any user other than tom creates a file or
directory underneath alpha, tom will</FONT></P>
<P><FONT SIZE=3D2>lose access to those files. The effect
is most painful when tom creates an excel spreadsheet or other document under
alpha, then jane edits and saves it. Since the Office products delete
a file before saving, the ownership of the file immediately changes to jane and
tom loses access to his own file.</FONT></P>
<P>
<FONT SIZE=3D2>I believe the bug is in sys_acl_set_file() in
lib/sysacls.c. Or at least, a fix could be applied in this call by
creating a default ACL and a user access ACL for the owner (and group) of the
file.</FONT></P>
<P>
<FONT SIZE=3D2>I've tested this with samba 2.2.3a and samba 2.2.5 on
linux kernels 2.4.17 with linux acl/ea patches from the 0.7 series as well as
2.4.19 with xattr+acl patch 0.8.50. THe problem also occurs on HP-UX
11.0 using JFS 3.3 (vxfs 4 filesystem layout) and samba
2.2.5.</FONT></P>
<P><FONT SIZE=3D2>Additional information :</FONT>
<BR>
<FONT SIZE=3D2>1. When acls are applied directly using setfacl
on the linux or hp-ux server, they are applied correctly. This does
not look like a problem with ACLs on either system.</FONT></P>
<P>
<FONT SIZE=3D2>2. Files created by windows clients start with
the correct ACLs. From looking at the samba code, I gather that this is because
smbd never actually touches the ACLs for newly created files and
directories. smbd only seems to manipulate ACLs when they're
changed from a windows client.</FONT></P>
<P>
<FONT SIZE=3D2>3. The "inherit acls" config
option does not fix this problem, which is not surprising since that's not
what the option is intended to do.</FONT></P>
</BODY>
</HTML>
------_=_NextPart_001_01C260B4.8812FA00--
