Re: [Samba] ACLs under Samba 3.3.0
Hi Miguel, On Wed, Feb 04, 2009 at 12:22:58AM +, Miguel Medalha wrote: > >> Here is the patch I've committed to the 3.3 code tree >> for this problem. It will be in the next release. Please >> try it out and let me know if it fixes your problem (it >> does here). >> > > Thank you so much! > > Will Sernet provide a 3.3.0-38 version as they did with 3.2.7? you can find the new packages containing the patch at ftp://ftp.sernet.de/pub/samba/experimental Karolin -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-37-0, fax: +49-551-37-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.SerNet.DE, mailto: Info @ SerNet.DE pgpDgPCuLgz5h.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Hi Miguel, On Mi, Feb 04, 2009 at 12:22:58 +, Miguel Medalha wrote: > >> Here is the patch I've committed to the 3.3 code tree >> for this problem. It will be in the next release. Please >> try it out and let me know if it fixes your problem (it >> does here). >> > > Thank you so much! > > Will Sernet provide a 3.3.0-38 version as they did with 3.2.7? yes, we will provide packages containing this patch plus a few others. We are just waiting for another fix and then we can build the packages. I guess they will be out by the end of this week. Karolin -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-37-0, fax: +49-551-37-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.SerNet.DE, mailto: Info @ SerNet.DE pgpQn1GHsFV2Y.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Here is the patch I've committed to the 3.3 code tree for this problem. It will be in the next release. Please try it out and let me know if it fixes your problem (it does here). Thank you so much! Will Sernet provide a 3.3.0-38 version as they did with 3.2.7? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 07:24:34PM +, Miguel Medalha wrote:
> Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from
> that under version 3.2.7? The release notes only talks about some
> "fixes".
>
> I installed version 3.3.0 and got completely different result with the
> same filesystem and the exact same samba configuration. The ACLs behaved
> strangely and appeared very different under Windows ACL editor. Users
> were now unable to delete the exact same files they had just created in
> a folder.
>
> When seen under the Windows ACL editor, the "Delete" permission was
> unselected. All efforts to activate it failed. Even resetting the
> permissions on the command line with setfacl did not have any effect. I
> then reverted to 3.2.7-38 and all was right again, without any
> modification whatsoever.
>
> Is this a bug or is it by design? If it is by design, then the release
> notes really should have warned against such a *huge* difference in
> behavior...
>
> I observed this under Samba Sernet 3.3.0+CentOS 5.2.
Here is the patch I've committed to the 3.3 code tree
for this problem. It will be in the next release. Please
try it out and let me know if it fixes your problem (it
does here).
Jeremy
diff --git a/source/include/smb.h b/source/include/smb.h
index e7f08a3..a98d151 100644
--- a/source/include/smb.h
+++ b/source/include/smb.h
@@ -1251,7 +1251,7 @@ struct bitmap {
/* Mapping of access rights to UNIX perms. for a UNIX directory. */
#define UNIX_DIRECTORY_ACCESS_RWX FILE_GENERIC_ALL
#define UNIX_DIRECTORY_ACCESS_RFILE_GENERIC_READ
-#define UNIX_DIRECTORY_ACCESS_WFILE_GENERIC_WRITE
+#define UNIX_DIRECTORY_ACCESS_W
(FILE_GENERIC_WRITE|FILE_DELETE_CHILD)
#define UNIX_DIRECTORY_ACCESS_XFILE_GENERIC_EXECUTE
#if 0
diff --git a/source/lib/util_seaccess.c b/source/lib/util_seaccess.c
index fdc10f2..0da7442 100644
--- a/source/lib/util_seaccess.c
+++ b/source/lib/util_seaccess.c
@@ -149,7 +149,9 @@ static uint32_t access_check_max_allowed(const struct
security_descriptor *sd,
}
/*
- the main entry point for access checking.
+ The main entry point for access checking. If returning ACCESS_DENIED
+ this function returns the denied bits in the uint32_t pointed
+ to by the access_granted pointer.
*/
NTSTATUS se_access_check(const struct security_descriptor *sd,
const NT_USER_TOKEN *token,
@@ -238,6 +240,7 @@ NTSTATUS se_access_check(const struct security_descriptor
*sd,
done:
if (bits_remaining != 0) {
+ *access_granted = bits_remaining;
return NT_STATUS_ACCESS_DENIED;
}
diff --git a/source/smbd/file_access.c b/source/smbd/file_access.c
index c535bc7..743e079 100644
--- a/source/smbd/file_access.c
+++ b/source/smbd/file_access.c
@@ -116,16 +116,11 @@ bool can_delete_file_in_directory(connection_struct
*conn, const char *fname)
* having the DELETE bit on the file itself and second if that does
* not help, by the DELETE_CHILD bit on the containing directory.
*
-* Here we check the other way round because with just posix
-* permissions looking at the file itself will never grant DELETE, so
-* by looking at the directory first we save one get_acl call.
+* Here we only check the directory permissions, we will
+* check the file DELETE permission separately.
*/
- if (can_access_file_acl(conn, dname, FILE_DELETE_CHILD)) {
- return true;
- }
-
- return can_access_file_acl(conn, fname, DELETE_ACCESS);
+ return can_access_file_acl(conn, dname, FILE_DELETE_CHILD);
}
/
diff --git a/source/smbd/open.c b/source/smbd/open.c
index 3c07dba..7e127ea 100644
--- a/source/smbd/open.c
+++ b/source/smbd/open.c
@@ -50,13 +50,15 @@ NTSTATUS smb1_file_se_access_check(const struct
security_descriptor *sd,
static NTSTATUS check_open_rights(struct connection_struct *conn,
const char *fname,
- uint32_t access_mask)
+ uint32_t access_mask,
+ uint32_t *access_granted)
{
/* Check if we have rights to open. */
NTSTATUS status;
- uint32_t access_granted = 0;
struct security_descriptor *sd;
+ *access_granted = 0;
+
status = SMB_VFS_GET_NT_ACL(conn, fname,
(OWNER_SECURITY_INFORMATION |
GROUP_SECURITY_INFORMATION |
@@ -73,9 +75,17 @@ static NTSTATUS check_open_rights(struct connection_struct
*conn,
status = smb1_file_se_access_check(sd,
conn->server_info->ptok,
access_mask,
- &access_granted);
+
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 01:53:08PM -0800, Jeremy Allison wrote: > Volker's changes are correct, in that delete access in POSIX does not > belong to a file itself, but to the containing directory. So really > we should remove the DELETE_ACCESS bit from both the file and the > directory ACL returned. This unfortunately breaks the fiction of > a rwx permission mapping directly into Windows FULL_CONTROL. What > your users can do with the file over Samba hasn't actually changed, > is they have write access to the directory they can still delete > the file, but the ACLs "look funny". > > I'll think some more about how we can restore the fiction for > the users without having to use the experimental native ACL > store. I have a patch for this but the problem is that it's a harder problem than it looks (still working on the patch). The issue is that whether a file can be deleted or not is a different issue to whether a particular ACL element has the DELETE bit set. A file can be deleted by an admin/root user, or by a user with se_restore privilege set, as well as by users matching an ACL entry. Currently the Samba code conflates the two cases, so I'm having to disentangle them as at the same time. This is an *interesting* change :-). I should have a final fix no later than Monday, but it might take me that long. Just an FYI for people waiting on this fix. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 10:49:35PM +, simo wrote: > > Jeremy, would it make sense to set the delete bit (or even full control) > depending on whether the user has write control over the parent > directory ? Doing this right now... -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Effectively, we should remove the "map acl full control" parameter as it now longer has any use except to break things. I'll mark it deprecated with the patch. Yes, I suppose you are right. Thank you for your efforts. I really appreciate your work. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, 2009-01-30 at 14:43 -0800, Jeremy Allison wrote: > On Fri, Jan 30, 2009 at 10:32:55PM +, Miguel Medalha wrote: > > > >> Volker's changes are correct, in that delete access in POSIX does not > >> belong to a file itself, but to the containing directory. So really > >> we should remove the DELETE_ACCESS bit from both the file and the > >> directory ACL returned. > > > > Without having the deep knowledge you have about this, it seems to me > > that this statement is indeed correct but... > >> This unfortunately breaks the fiction of a rwx permission mapping directly > >> into Windows FULL_CONTROL. > > > > I can live with that as long as can can set full permissions for users. > > The ideal would be: > > > > 'map acl full control = yes' -> do what it describes > > > > 'map acl full control = no' -> enable us to set the "Delete" permission > > (and others) separately. > > > > The problem with 3.3.0 is that I cannot set the delete permission and as > > such users with rwx at the filesystem level cannot delete the files. > > Ok, I'm preparing a patch for this. Effectively, we should > remove the "map acl full control" parameter as it now longer > has any use except to break things. I'll mark it deprecated > with the patch. Jeremy, would it make sense to set the delete bit (or even full control) depending on whether the user has write control over the parent directory ? Maybe make this behavior could be triggerd by "map acl full control". Simo. -- Simo Sorce Samba Team GPL Compliance Officer Principal Software Engineer at Red Hat, Inc. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Can you give me an exact scenario to reproduce. I can certainly delete files I have created in my test env. I have a directory from which getfacl --t obtains the following: USER Adminrwx rwx GROUP Admins rwx rwx group Admins rwx rwx group Editores rwx rwx group Fotografos --x --x group Graficos rwx rwx group Jornalistas --x --x maskrwx rwx other --- --- --- The share definition contains the following: [Editor] comment = Editores path = /data/Jornal/Editor valid users = @Admins, @Editores, @Graficos write list = @Admins, @Editores, @Graficos --- The acl parameters explicitly set in my smb.conf are the following: acl compatibility = win2k inherit acls = Yes map acl inherit = Yes --- A member of the "Graficos" group extracted an attachment from an email message and put it in that directory. A member of group "Editores", after having read the file, tried to delete it and was prevented from doing it. He then asked the first user to delete the file himself, which he could not do. After similar behavior was found with several files in other directories, the problem was reported to me. I immediately noticed that the "Delete" permission had been cleared. I tried to reset it but was unable to do so. As work was pressing, I reverted to 3.2.7 and all was well again. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 10:32:55PM +, Miguel Medalha wrote: > >> Volker's changes are correct, in that delete access in POSIX does not >> belong to a file itself, but to the containing directory. So really >> we should remove the DELETE_ACCESS bit from both the file and the >> directory ACL returned. > > Without having the deep knowledge you have about this, it seems to me > that this statement is indeed correct but... >> This unfortunately breaks the fiction of a rwx permission mapping directly >> into Windows FULL_CONTROL. > > I can live with that as long as can can set full permissions for users. > The ideal would be: > > 'map acl full control = yes' -> do what it describes > > 'map acl full control = no' -> enable us to set the "Delete" permission > (and others) separately. > > The problem with 3.3.0 is that I cannot set the delete permission and as > such users with rwx at the filesystem level cannot delete the files. Ok, I'm preparing a patch for this. Effectively, we should remove the "map acl full control" parameter as it now longer has any use except to break things. I'll mark it deprecated with the patch. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Volker's changes are correct, in that delete access in POSIX does not belong to a file itself, but to the containing directory. So really we should remove the DELETE_ACCESS bit from both the file and the directory ACL returned. Without having the deep knowledge you have about this, it seems to me that this statement is indeed correct but... This unfortunately breaks the fiction of a rwx permission mapping directly into Windows FULL_CONTROL. I can live with that as long as can can set full permissions for users. The ideal would be: 'map acl full control = yes' -> do what it describes 'map acl full control = no' -> enable us to set the "Delete" permission (and others) separately. The problem with 3.3.0 is that I cannot set the delete permission and as such users with rwx at the filesystem level cannot delete the files. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 05:08:14PM -0500, Ryan B. Lynch wrote:
>
> I tested this about four weeks ago, comparing operations from Windows
> clients against our Samba 3.2.7 server and another machine running a
> 3.3.0 pre-release checkout. The ACL rights assignments did appear to be
> different, but I believe that the actual results were different, too.
>
> That is to day, a Windows user could delete, rename, or take ownership
> of a file/directory on which that user had UNIX 'rwx' rights, but only
> on 3.2.7. This didn't work on 3.3.0.
The difference in 3.2.x and 3.3.x here is that for deleting or
renaming a file 3.2.x uses the request :
can_access_file_acl(conn, dname, &sbuf, FILE_WRITE_DATA);
whereas 3.3.x uses the more correct checks :
if (can_access_file_acl(conn, dname, FILE_DELETE_CHILD)) {
return true;
}
return can_access_file_acl(conn, fname, DELETE_ACCESS);
This has probably tightened the restriction on who can do what
to be closer to the Windows access restrictions. This is intentional,
as I think the 3.2.x model was not correct (too permissive).
> But I want to be careful before I say I'm sure, because you (Jeremy)
> certainly know this subject better than me. I'm going to test those
> same operations over the weekend, and I'll confirm whether it's just a
> different appearance or whether it affects the actual operations. I
> will also turn the debug logging up to the max, and I'll attach that to
> bug #6005 with an update.
> For our users, it's a requirement--the business process requires one
> user to be able to rename, delete, etc. directory trees and files that
> other users create.
So long as they have write access into the directory they should
be able to do this.
Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Friday 30 January 2009 15:53:08 Jeremy Allison wrote: > On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote: > > > I would describe the problem *slightly* differently from Miguel. I do > > > not think that ACLs are the real problem, because the bug behaviour > > > exists regardless of whether you're using filesystem ACLs or not. > > > > > > The problem seems to be that the configuration option 'acl map full > > > control' isn't working anymore under 3.3. This option took me a long > > > time to understand, because it refers to Windows ACLs, not filesystem > > > ACLs. If the option is set (which is the default under both 3.2.7 and > > > 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' > > > rights under Windows. This is regardless of whether the 'rwx' > > > permissions come from the base UNIX permissions or POSIX ACLs. > > > > > > 3.2.7 works as the man page describes, but 3.3.0 does not. Under > > > 3.3.0, a user with 'rwx' will have every Windows right except for > > > 'Delete' and 'Full Control'. Even the file's owner will lack those two > > > rights. Nonetheless, the owner will be able to delete or rename the > > > file, but not any other users, even if they apparently have identical > > > rights. > > > > > > Also, this behaviour seems to persist whether you explicitly turn 'acl > > > map full control' on or off. We also tried a few dozen combinations of > > > other permission, ownership, and ACL-related options in 'smb.conf', and > > > none of them worked. > > > > Ok, here are the two commits that affected this issue to make it differ > > from 3.2.x. > > > > commit 51b5364c2afb3a18df4bec2bc1624760ccc01676 > > Author: Volker Lendecke > > Date: Tue Jun 17 16:22:43 2008 +0200 > > > > RWX on a file does not imply DELETE access > > Without this the changed checks in can_delete_file_in_directory give > > DELETE access where there is none. So we can end up granting the > > ntcreate&x preparing the unlink where we should not, which leads to a > > NT_STATUS_ACCESS_DENIED at close time later, which in turn does *not* > > give the access denied error message in the Windows GUI. > > > > can_delete_file_in_directory will grant access now by looking at the > > directory permissions. > > > > commit daa9b056645a45edfb3a70e3536011ebe5678970 > > Author: Volker Lendecke > > Date: Thu Jun 19 14:53:46 2008 +0200 > > > > Fix checks in can_delete_file_in_directory() > > With at least NFSv4 ACLs around the write permission for the owner is > > a bogus check if we can delete a file in a directory. Like in Windows, > > there are two ways which can grant us such: First, the DELETE permission > > on the file itself, or if that does not help, the DELETE_CHILD permission > > on the directory. It might be a bit more code that runs, but essentially > > we should end up with the same set of syscalls in the non-acl case. > > > > This looks like a compatibility change to make us work better > > with NFSv4 underlying ACLs, not POSIX ones. > > > > I'll do some more digging. > > Volker's changes are correct, in that delete access in POSIX does not > belong to a file itself, but to the containing directory. So really > we should remove the DELETE_ACCESS bit from both the file and the > directory ACL returned. This unfortunately breaks the fiction of > a rwx permission mapping directly into Windows FULL_CONTROL. What > your users can do with the file over Samba hasn't actually changed, > is they have write access to the directory they can still delete > the file, but the ACLs "look funny". > > I'll think some more about how we can restore the fiction for > the users without having to use the experimental native ACL > store. > > Jeremy. Jeremy, Ryan's environment requires that users have full control over all files in a directory. So long as they have read and write access (in the directory and for the file) they must be able to delete the file and/or rename it, even where it belongs to another user. We have not be been able to get this to work with 3.3.0. It is working without any problems with 3.2.7. It does appear that something has changed in 3.3.0 compared with 3.2.7. Ryan is using 3.3.0 so that he can use CTDB. We are in the process of rebuilding the clustered environment and will be able to test the full combination some time next week. Right now we are running tests with samba-3.3.0 without using CTDB but using binaries that have it enabled. Site operators don't really care what the Full Control flags look like, so long as they can delete files that were created by another user. Cheers, John T. -- John H Terpstra "If at first you don't succeed, don't go sky-diving!" -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 10:03:57PM +, Miguel Medalha wrote: > >> How are they trying to delete the files ? Using Windows explorer or >> cmd.exe or a custom app ? >> >> >> > Using Windows Explorer. This is a CentOS machine serving a network of > Windows XP workstations. Can you give me an exact scenario to reproduce. I can certainly delete files I have created in my test env. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Jeremy Allison wrote: On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote: > > I would describe the problem *slightly* differently from Miguel. I do > > not think that ACLs are the real problem, because the bug behaviour > > exists regardless of whether you're using filesystem ACLs or not. > > > > The problem seems to be that the configuration option 'acl map full > > control' isn't working anymore under 3.3. This option took me a long > > time to understand, because it refers to Windows ACLs, not filesystem > > ACLs. If the option is set (which is the default under both 3.2.7 and > > 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' > > rights under Windows. This is regardless of whether the 'rwx' > > permissions come from the base UNIX permissions or POSIX ACLs. > > > > 3.2.7 works as the man page describes, but 3.3.0 does not. Under 3.3.0, > > a user with 'rwx' will have every Windows right except for 'Delete' and > > 'Full Control'. Even the file's owner will lack those two rights. > > Nonetheless, the owner will be able to delete or rename the file, but > > not any other users, even if they apparently have identical rights. > > > > Also, this behaviour seems to persist whether you explicitly turn 'acl > > map full control' on or off. We also tried a few dozen combinations of > > other permission, ownership, and ACL-related options in 'smb.conf', and > > none of them worked. > > Ok, here are the two commits that affected this issue to make it differ > from 3.2.x. > > commit 51b5364c2afb3a18df4bec2bc1624760ccc01676 > Author: Volker Lendecke > Date: Tue Jun 17 16:22:43 2008 +0200 > > RWX on a file does not imply DELETE access > Without this the changed checks in can_delete_file_in_directory give DELETE > access where there is none. So we can end up granting the ntcreate&x preparing > the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED at > close time later, which in turn does *not* give the access denied error message > in the Windows GUI. > > can_delete_file_in_directory will grant access now by looking at the directory > permissions. > > commit daa9b056645a45edfb3a70e3536011ebe5678970 > Author: Volker Lendecke > Date: Thu Jun 19 14:53:46 2008 +0200 > > Fix checks in can_delete_file_in_directory() > With at least NFSv4 ACLs around the write permission for the owner is a bogus > check if we can delete a file in a directory. Like in Windows, there are two > ways which can grant us such: First, the DELETE permission on the file itself, > or if that does not help, the DELETE_CHILD permission on the directory. It > might be a bit more code that runs, but essentially we should end up with the > same set of syscalls in the non-acl case. > > This looks like a compatibility change to make us work better > with NFSv4 underlying ACLs, not POSIX ones. > > I'll do some more digging. Volker's changes are correct, in that delete access in POSIX does not belong to a file itself, but to the containing directory. So really we should remove the DELETE_ACCESS bit from both the file and the directory ACL returned. This unfortunately breaks the fiction of a rwx permission mapping directly into Windows FULL_CONTROL. What your users can do with the file over Samba hasn't actually changed, is they have write access to the directory they can still delete the file, but the ACLs "look funny". I tested this about four weeks ago, comparing operations from Windows clients against our Samba 3.2.7 server and another machine running a 3.3.0 pre-release checkout. The ACL rights assignments did appear to be different, but I believe that the actual results were different, too. That is to day, a Windows user could delete, rename, or take ownership of a file/directory on which that user had UNIX 'rwx' rights, but only on 3.2.7. This didn't work on 3.3.0. But I want to be careful before I say I'm sure, because you (Jeremy) certainly know this subject better than me. I'm going to test those same operations over the weekend, and I'll confirm whether it's just a different appearance or whether it affects the actual operations. I will also turn the debug logging up to the max, and I'll attach that to bug #6005 with an update. I'll think some more about how we can restore the fiction for the users without having to use the experimental native ACL store. For our users, it's a requirement--the business process requires one user to be able to rename, delete, etc. directory trees and files that other users create. -Ryan -- Ryan B. Lynch Engineer Innovative Discovery, LLC http://www.id-edd.com/ 347.633.0512 ryan.ly...@id-edd.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
How are they trying to delete the files ? Using Windows explorer or cmd.exe or a custom app ? Using Windows Explorer. This is a CentOS machine serving a network of Windows XP workstations. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 09:59:58PM +, Miguel Medalha wrote: > >> What your users can do with the file over Samba hasn't actually changed, >> is they have write access to the directory they can still delete >> the file, but the ACLs "look funny". >> >> > > No, they can't. I was alerted to this problem precisely because users > who have full access to the directory suddenly could not delete files > inside it. How are they trying to delete the files ? Using Windows explorer or cmd.exe or a custom app ? Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
What your users can do with the file over Samba hasn't actually changed, is they have write access to the directory they can still delete the file, but the ACLs "look funny". No, they can't. I was alerted to this problem precisely because users who have full access to the directory suddenly could not delete files inside it. The ACLs "look funny" and "are funny". -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote: > > I would describe the problem *slightly* differently from Miguel. I do > > not think that ACLs are the real problem, because the bug behaviour > > exists regardless of whether you're using filesystem ACLs or not. > > > > The problem seems to be that the configuration option 'acl map full > > control' isn't working anymore under 3.3. This option took me a long > > time to understand, because it refers to Windows ACLs, not filesystem > > ACLs. If the option is set (which is the default under both 3.2.7 and > > 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' > > rights under Windows. This is regardless of whether the 'rwx' > > permissions come from the base UNIX permissions or POSIX ACLs. > > > > 3.2.7 works as the man page describes, but 3.3.0 does not. Under 3.3.0, > > a user with 'rwx' will have every Windows right except for 'Delete' and > > 'Full Control'. Even the file's owner will lack those two rights. > > Nonetheless, the owner will be able to delete or rename the file, but > > not any other users, even if they apparently have identical rights. > > > > Also, this behaviour seems to persist whether you explicitly turn 'acl > > map full control' on or off. We also tried a few dozen combinations of > > other permission, ownership, and ACL-related options in 'smb.conf', and > > none of them worked. > > Ok, here are the two commits that affected this issue to make it differ > from 3.2.x. > > commit 51b5364c2afb3a18df4bec2bc1624760ccc01676 > Author: Volker Lendecke > Date: Tue Jun 17 16:22:43 2008 +0200 > > RWX on a file does not imply DELETE access > Without this the changed checks in can_delete_file_in_directory give > DELETE > access where there is none. So we can end up granting the ntcreate&x > preparing > the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED > at > close time later, which in turn does *not* give the access denied error > message > in the Windows GUI. > > can_delete_file_in_directory will grant access now by looking at the > directory > permissions. > > commit daa9b056645a45edfb3a70e3536011ebe5678970 > Author: Volker Lendecke > Date: Thu Jun 19 14:53:46 2008 +0200 > > Fix checks in can_delete_file_in_directory() > With at least NFSv4 ACLs around the write permission for the owner is a > bogus > check if we can delete a file in a directory. Like in Windows, there are > two > ways which can grant us such: First, the DELETE permission on the file > itself, > or if that does not help, the DELETE_CHILD permission on the directory. It > might be a bit more code that runs, but essentially we should end up with > the > same set of syscalls in the non-acl case. > > This looks like a compatibility change to make us work better > with NFSv4 underlying ACLs, not POSIX ones. > > I'll do some more digging. Volker's changes are correct, in that delete access in POSIX does not belong to a file itself, but to the containing directory. So really we should remove the DELETE_ACCESS bit from both the file and the directory ACL returned. This unfortunately breaks the fiction of a rwx permission mapping directly into Windows FULL_CONTROL. What your users can do with the file over Samba hasn't actually changed, is they have write access to the directory they can still delete the file, but the ACLs "look funny". I'll think some more about how we can restore the fiction for the users without having to use the experimental native ACL store. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
I would describe the problem *slightly* differently from Miguel. I do not think that ACLs are the real problem, because the bug behaviour exists regardless of whether you're using filesystem ACLs or not. You may be right. I didn't have the time to thoroughly test it because I had to immediately revert to 3.2.7; there was work to be done. The problem seems to be that the configuration option 'acl map full control' isn't working anymore under 3.3. If that is the case, it is not working neither "on" nor "off". f the option is set (which is the default under both 3.2.7 and 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' rights under Windows. This is regardless of whether the 'rwx' permissions come from the base UNIX permissions or POSIX ACLs. I can live without 'acl map full control' as long as I can set the appropriate permissions. I tried to enable the "Delete" permission with the Windows ACL editor and it didn't work, with both 'acl map full control' "on" or "off". Maybe there is something here which deserves further investigation. Under 3.3.0, a user with 'rwx' will have every Windows right except for 'Delete' and 'Full Control'. Even the file's owner will lack those two rights. Nonetheless, the owner will be able to delete or rename the file, but not any other users, even if they apparently have identical rights. Yes, that describes what I saw. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 03:35:24PM -0500, Ryan B. Lynch wrote: > Miguel Medalha wrote: >> >>> Much of the ACL code has been rewritten to allow underlying >>> filesystems to implement "native" NT ACLs directly (...) >> >> Good! >> >>> but the functionality should be the same as 3.2.x when not >>> using the "experimental" ACL modules. >>> >>> >> >> I am not using the ACL modules and the functionality is definitely NOT >> the same. My users complained immediately. > > > We've been working to implement Samba 3.3 at our site since December. We > saw the same behaviour that Miguel describes since RC2, and we see it > today in a test with the final 3.3.0 release. > > We opened a bug report, #6005, but we didn't have a chance to post the > debug logs that Volcker requested, and it's closed, now. We will > probably do that next week and reopen it. Here's the link: > https://bugzilla.samba.org/show_bug.cgi?id=6005 > > I would describe the problem *slightly* differently from Miguel. I do > not think that ACLs are the real problem, because the bug behaviour > exists regardless of whether you're using filesystem ACLs or not. > > The problem seems to be that the configuration option 'acl map full > control' isn't working anymore under 3.3. This option took me a long > time to understand, because it refers to Windows ACLs, not filesystem > ACLs. If the option is set (which is the default under both 3.2.7 and > 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' > rights under Windows. This is regardless of whether the 'rwx' > permissions come from the base UNIX permissions or POSIX ACLs. > > 3.2.7 works as the man page describes, but 3.3.0 does not. Under 3.3.0, > a user with 'rwx' will have every Windows right except for 'Delete' and > 'Full Control'. Even the file's owner will lack those two rights. > Nonetheless, the owner will be able to delete or rename the file, but > not any other users, even if they apparently have identical rights. > > Also, this behaviour seems to persist whether you explicitly turn 'acl > map full control' on or off. We also tried a few dozen combinations of > other permission, ownership, and ACL-related options in 'smb.conf', and > none of them worked. Ok, here are the two commits that affected this issue to make it differ from 3.2.x. commit 51b5364c2afb3a18df4bec2bc1624760ccc01676 Author: Volker Lendecke Date: Tue Jun 17 16:22:43 2008 +0200 RWX on a file does not imply DELETE access Without this the changed checks in can_delete_file_in_directory give DELETE access where there is none. So we can end up granting the ntcreate&x preparing the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED at close time later, which in turn does *not* give the access denied error message in the Windows GUI. can_delete_file_in_directory will grant access now by looking at the directory permissions. commit daa9b056645a45edfb3a70e3536011ebe5678970 Author: Volker Lendecke Date: Thu Jun 19 14:53:46 2008 +0200 Fix checks in can_delete_file_in_directory() With at least NFSv4 ACLs around the write permission for the owner is a bogus check if we can delete a file in a directory. Like in Windows, there are two ways which can grant us such: First, the DELETE permission on the file itself, or if that does not help, the DELETE_CHILD permission on the directory. It might be a bit more code that runs, but essentially we should end up with the same set of syscalls in the non-acl case. This looks like a compatibility change to make us work better with NFSv4 underlying ACLs, not POSIX ones. I'll do some more digging. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Miguel Medalha wrote: Much of the ACL code has been rewritten to allow underlying filesystems to implement "native" NT ACLs directly (...) Good! but the functionality should be the same as 3.2.x when not using the "experimental" ACL modules. I am not using the ACL modules and the functionality is definitely NOT the same. My users complained immediately. We've been working to implement Samba 3.3 at our site since December. We saw the same behaviour that Miguel describes since RC2, and we see it today in a test with the final 3.3.0 release. We opened a bug report, #6005, but we didn't have a chance to post the debug logs that Volcker requested, and it's closed, now. We will probably do that next week and reopen it. Here's the link: https://bugzilla.samba.org/show_bug.cgi?id=6005 I would describe the problem *slightly* differently from Miguel. I do not think that ACLs are the real problem, because the bug behaviour exists regardless of whether you're using filesystem ACLs or not. The problem seems to be that the configuration option 'acl map full control' isn't working anymore under 3.3. This option took me a long time to understand, because it refers to Windows ACLs, not filesystem ACLs. If the option is set (which is the default under both 3.2.7 and 3.3.0), a user with 'rwx' UNIX permissions should get 'Full Control' rights under Windows. This is regardless of whether the 'rwx' permissions come from the base UNIX permissions or POSIX ACLs. 3.2.7 works as the man page describes, but 3.3.0 does not. Under 3.3.0, a user with 'rwx' will have every Windows right except for 'Delete' and 'Full Control'. Even the file's owner will lack those two rights. Nonetheless, the owner will be able to delete or rename the file, but not any other users, even if they apparently have identical rights. Also, this behaviour seems to persist whether you explicitly turn 'acl map full control' on or off. We also tried a few dozen combinations of other permission, ownership, and ACL-related options in 'smb.conf', and none of them worked. -Ryan -- Ryan B. Lynch Engineer Innovative Discovery, LLC http://www.id-edd.com/ 347.633.0512 ryan.ly...@id-edd.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
Much of the ACL code has been rewritten to allow underlying filesystems to implement "native" NT ACLs directly (...) Good! but the functionality should be the same as 3.2.x when not using the "experimental" ACL modules. I am not using the ACL modules and the functionality is definitely NOT the same. My users complained immediately. Regards -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 11:58:16AM -0800, Jeremy Allison wrote: > On Fri, Jan 30, 2009 at 08:50:50PM +0100, Volker Lendecke wrote: > > On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote: > > > Not yet, it's on my list of things to document and > > > discuss in a talk at SambaXP this year. > > > > As you mention it -- did I miss your talk submitted? > > Just hit the "submit" button on the Web site :-) Thanks, got it :-) Volker pgpCZUxf99zeQ.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 08:50:50PM +0100, Volker Lendecke wrote: > On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote: > > Not yet, it's on my list of things to document and > > discuss in a talk at SambaXP this year. > > As you mention it -- did I miss your talk submitted? Just hit the "submit" button on the Web site :-) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote: > Not yet, it's on my list of things to document and > discuss in a talk at SambaXP this year. As you mention it -- did I miss your talk submitted? Volker pgpsFkI5d4z9U.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACLs under Samba 3.3.0
On Fri, Jan 30, 2009 at 07:24:34PM +, Miguel Medalha wrote: > Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from > that under version 3.2.7? The release notes only talks about some > "fixes". > > I installed version 3.3.0 and got completely different result with the > same filesystem and the exact same samba configuration. The ACLs behaved > strangely and appeared very different under Windows ACL editor. Users > were now unable to delete the exact same files they had just created in > a folder. > > When seen under the Windows ACL editor, the "Delete" permission was > unselected. All efforts to activate it failed. Even resetting the > permissions on the command line with setfacl did not have any effect. I > then reverted to 3.2.7-38 and all was right again, without any > modification whatsoever. > > Is this a bug or is it by design? If it is by design, then the release > notes really should have warned against such a *huge* difference in > behavior... Much of the ACL code has been rewritten to allow underlying filesystems to implement "native" NT ACLs directly, but the functionality should be the same as 3.2.x when not using the "experimental" ACL modules. > On the subject of ACLs, is there any documentation available about the > experimental vfs modules acl_tdb and acl_xattr? Not yet, it's on my list of things to document and discuss in a talk at SambaXP this year. Jeremy -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] ACLs under Samba 3.3.0
Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from that under version 3.2.7? The release notes only talks about some "fixes". I installed version 3.3.0 and got completely different result with the same filesystem and the exact same samba configuration. The ACLs behaved strangely and appeared very different under Windows ACL editor. Users were now unable to delete the exact same files they had just created in a folder. When seen under the Windows ACL editor, the "Delete" permission was unselected. All efforts to activate it failed. Even resetting the permissions on the command line with setfacl did not have any effect. I then reverted to 3.2.7-38 and all was right again, without any modification whatsoever. Is this a bug or is it by design? If it is by design, then the release notes really should have warned against such a *huge* difference in behavior... I observed this under Samba Sernet 3.3.0+CentOS 5.2. On the subject of ACLs, is there any documentation available about the experimental vfs modules acl_tdb and acl_xattr? Than you for your attention. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
