allowing smbcacls to modify the acl when it's not allowed to modi fy the owner

Martin Dorey mdorey at bluearc.com
Wed Jun 4 00:43:50 GMT 2003


I wanted it to use this command to add an ACE to an ACL:

smbcacls //ukfile/profiles martin -U "terastack\\martind" -A
"ACL:TERASTACK\\martind:ALLOWED/3/FULL"

It silently failed and returned a zero status.  I was initially using
today's Debian/unstable version but the CVS HEAD turned out to exhibit the
same symptom.  A network trace reveals that smbcacls is trying to set the
owner and group - and getting ERROR_INVALID_OWNER back - even though I've
only asked it to modify the ACL.  Capture of the request and response
attached.

Though I have WriteOwner right to the directory in question, the Win2K
server in question won't let me "change" the owner - even if I'm trying to
set it to the same SID that it already is - as the particular SID in
question isn't in my access token.  From previous experiments, I think this
is normal behaviour on the part of MS servers.  Here's the SD:

$ smbcacls //ukfile/profiles martin -U "terastack\\martind" 
REVISION:1
OWNER:BUILTIN\Administrators
GROUP:TERASTACK\Domain Users
ACL:\Everyone:ALLOWED/9/0x10000000
ACL:\Everyone:ALLOWED/2/FULL
ACL:TERASTACK\Domain Admins:ALLOWED/9/0x10000000
ACL:TERASTACK\Domain Admins:ALLOWED/2/FULL

main() calls cacl_set() which calls cli_set_secdesc() which will try to set
the owner and group if the security descriptor it's passed has those fields.
Perhaps the right fix is then to not initialise the owner and group fields
in the security descriptor that's passed in:

Index: utils/smbcacls.c
===================================================================
RCS file: /cvsroot/samba/source/utils/smbcacls.c,v
retrieving revision 1.89
diff -u -r1.89 smbcacls.c
--- utils/smbcacls.c	10 May 2003 11:47:29 -0000	1.89
+++ utils/smbcacls.c	4 Jun 2003 00:01:33 -0000
@@ -680,7 +680,7 @@
 	sort_acl(old->dacl);
 
 	/* Create new security descriptor and set it */
-	sd = make_sec_desc(ctx,old->revision, old->owner_sid, old->grp_sid, 
+	sd = make_sec_desc(ctx,old->revision, NULL, NULL,
 			   NULL, old->dacl, &sd_size);
 
 	fnum = cli_nt_create(cli, filename, CREATE_ACCESS_WRITE);


That did the trick for me.

Why did it fail silently?  Perhaps there was a missing change here:

Revision 1.15 / (download) - annotate - [select for diffs] , Mon Aug 27
17:52:21 2001 UTC (21 months ago) by tridge 
Branch: MAIN 
Changes since 1.14: +6 -20 lines
Diff to previous 1.14 (colored) 
started converting NTSTATUS to be a structure on systems with gcc in order
to make it type incompatible with BOOL so we catch errors sooner. This has
already found a number of bugs

When tridge changed cli_receive_trans() to, um, look for NT errors as well
as DOS ones(? - I don't really know what I'm talking about here):

===================================================================
RCS file: /cvsroot/samba/source/libsmb/clitrans.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- samba/source/libsmb/clitrans.c	2001/08/27 08:19:40	1.14
+++ samba/source/libsmb/clitrans.c	2001/08/27 17:52:21	1.15
@@ -145,8 +145,7 @@
 	int total_data=0;
 	int total_param=0;
 	int this_data,this_param;
-	uint8 eclass;
-	uint32 ecode;
+	NTSTATUS status;
 	char *tdata;
 	char *tparam;
 
@@ -170,19 +169,9 @@
 	 * to a trans call. This is not an error and should not
 	 * be treated as such.
 	 */
-
-	if (cli_is_error(cli)) {
-		if (cli_is_dos_error(cli)) {
-			cli_dos_error(cli, &eclass, &ecode);
-
-			if(cli->nt_pipe_fnum == 0)
-				return(False);
-
-			if(!(eclass == ERRDOS && ecode == ERRmoredata)) {
-				if (eclass != 0 && (ecode != (0x80000000 |
STATUS_BUFFER_OVERFLOW)))
-					return(False);
-			}
-		}
+	status = cli_nt_error(cli);
+	
+	if (NT_STATUS_IS_ERR(status)) {
 		return False;
 	}
 
@@ -251,11 +240,8 @@
 				 CVAL(cli->inbuf,smb_com)));
 			return(False);
 		}
-		if (cli_is_dos_error(cli)) {
-                        cli_dos_error(cli, &eclass, &ecode);
-                        if(cli->nt_pipe_fnum == 0 || 
-                           !(eclass == ERRDOS && ecode == ERRmoredata))
-				return(False);
+		if (NT_STATUS_IS_ERR(cli_nt_error(cli))) {
+			return(False);
 		}
 	}

Perhaps there should be a corresponding change in cli_receive_nt_trans():

Index: source/libsmb/clitrans.c
===================================================================
RCS file: /cvsroot/samba/source/libsmb/clitrans.c,v
retrieving revision 1.20
diff -u -r1.20 clitrans.c
--- source/libsmb/clitrans.c	15 Mar 2003 06:43:37 -0000	1.20
+++ source/libsmb/clitrans.c	4 Jun 2003 00:29:57 -0000
@@ -433,10 +433,8 @@
 	 * to a trans call. This is not an error and should not
 	 * be treated as such.
 	 */
-	if (cli_is_dos_error(cli)) {
-                cli_dos_error(cli, &eclass, &ecode);
-		if (cli->nt_pipe_fnum == 0 || !(eclass == ERRDOS && ecode ==
ERRmoredata))
-			return(False);
+	if (NT_STATUS_IS_ERR(cli_nt_error(cli))) {
+		return(False);
 	}
 
 	/* parse out the lengths */
@@ -543,11 +541,8 @@
 				 CVAL(cli->inbuf,smb_com)));
 			return(False);
 		}
-		if (cli_is_dos_error(cli)) {
-                        cli_dos_error(cli, &eclass, &ecode);
-			if(cli->nt_pipe_fnum == 0 || 
-                           !(eclass == ERRDOS && ecode == ERRmoredata))
-				return(False);
+		if (NT_STATUS_IS_ERR(cli_nt_error(cli))) {
+			return(False);
 		}
 		/* parse out the total lengths again - they can shrink! */
 		if (SVAL(cli->inbuf,smb_ntr_TotalDataCount) < total_data)

This changed the output of a version without the first fix to: 

NT_TRANSACT_SET_SECURITY_DESC failed
ERROR: secdesc set failed: NT_STATUS_INVALID_OWNER

And it then returned a non-zero status.  Reapplying my first patch again
resulted in no output, a zero return code and correct behaviour - as hoped.
Hardly conclusive proof that the patch is a good 'un but maybe enough that
someone who knows what they're doing takes me seriously?

Cheers,

-- 



*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin at bluearc.com
*********************************************************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: invalid-owner.cap
Type: application/octet-stream
Size: 543 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20030604/c6fa30fb/invalid-owner.obj


More information about the samba-technical mailing list