Roel van Meer writes:
Since I've upgraded from samba 3.0.23c to 3.0.25c my ACL's don't work as
expected anymore. I'm not sure where the problem is, however. The symptoms
are simple: with 3.0.23c, I could grant and revoke user, group and world
write access to and from files in a share. With 3.0.25c, I can't do that
anymore. When I deselect group or world read access and apply the changes,
I don't get an error, but the permissions aren't changed either.
After reading some source code, I think I found where the problem pops up.
Since 3.0.25c, the set_nt_acl() function calls append_parent_acl(), which in
turn calls unix_mode(). The unix_mode() function has documentation that
states that "everybody gets read bit set", which is what causes the trouble.
When I comment the code that adds these ACEs to the applied set, everything
works as expected. However, I'm really not sure which things (if any) will
break now.
Attached to this mail is a rough patch that comments the code causing the
problem. It's tested insofar that basic ACL functionality works as
expected, but YMMV. I've filed a bug report about this:, nr 5094.
Regards,
roel
diff -ruN source.orig/smbd/posix_acls.c source/smbd/posix_acls.c
--- source.orig/smbd/posix_acls.c 2007-11-15 04:15:04.000000000 +0100
+++ source/smbd/posix_acls.c 2007-11-20 16:39:11.000000000 +0100
@@ -3243,6 +3243,9 @@
* Append u/g/w.
*/
+ /* We do not append these parent permissions, because they always cause
+ * user, group and world to have read access.
+ * It might be incorrect or inappropriate to not add these, however.
status = append_ugw_ace(fsp, psbuf, unx_mode, S_IRUSR, &new_ace[i++]);
if (!NT_STATUS_IS_OK(status)) {
return status;
@@ -3255,6 +3258,7 @@
if (!NT_STATUS_IS_OK(status)) {
return status;
}
+ */
/* Finally append any inherited ACEs. */
for (j = 0; j < parent_sd->dacl->num_aces; j++) {
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
