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
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
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
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
[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
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
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 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: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
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
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
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 v...@samba.org 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 ntcreatex 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 v...@samba.org 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
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 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 v...@samba.org 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 ntcreatex 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 v...@samba.org 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
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 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
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
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 v...@samba.org 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 ntcreatex 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 v...@samba.org 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
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
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 v...@samba.org 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 ntcreatex 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 v...@samba.org 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 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
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 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
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, 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 s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.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
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, 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
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
[Samba] ACLS and samba
HI, I guess this question have been asked before:- I am running 3.0.12 for samba with acls. I have a samba share folder called abc with groups art able to write. group:art:rwx Whenever i write with a user from the art group to the folder, the group id of the file changes to the id of the user instead of remaining as art. What do i need to configure so that art group stays as the group id for that file? Thanks. adrian P/s: What does inherit permissions in the smb.conf do? Does it help? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLS and samba
On Thu, Mar 24, 2005 at 12:06:56AM +0800, Adrian Chow wrote: HI, I guess this question have been asked before:- I am running 3.0.12 for samba with acls. I have a samba share folder called abc with groups art able to write. group:art:rwx Whenever i write with a user from the art group to the folder, the group id of the file changes to the id of the user instead of remaining as art. What do i need to configure so that art group stays as the group id for that file? You need to set the set GID bit on the directory. This ensures that files created within it inherit the group of the directory, not the effective group id of the creating process. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLS and samba
On Thu, Mar 24, 2005 at 12:06:56AM +0800, Adrian Chow wrote: I guess this question have been asked before:- I am running 3.0.12 for samba with acls. I have a samba share folder called abc with groups art able to write. group:art:rwx Whenever i write with a user from the art group to the folder, the group id of the file changes to the id of the user instead of remaining as art. Set a default ACL for that group like: setfacl -m d:g:groupname:rwx /path/to/the/dir P/s: What does inherit permissions in the smb.conf do? Does it help? Use inherit acls = Yes Lars -- Lars MLLER [la(r)z ml] SuSE Linux, Maxfeldstrae 5, 90409 Nrnberg, Germany pgpjAoQIgbw5w.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLS and samba
Hi jeremy, Thanks. But if after I did that and I create a directory underneath it, The new directory will not have guid set... how to solve it? Thanks again. adrian - Original Message - From: Jeremy Allison [EMAIL PROTECTED] To: Adrian Chow [EMAIL PROTECTED] Cc: samba@lists.samba.org Sent: Thu, 24 Mar 2005 02:37:08 +0800 Subject: Re: [Samba] ACLS and samba On Thu, Mar 24, 2005 at 12:06:56AM +0800, Adrian Chow wrote: HI, I guess this question have been asked before:- I am running 3.0.12 for samba with acls. I have a samba share folder called abc with groups art able to write. group:art:rwx Whenever i write with a user from the art group to the folder, the group id of the file changes to the id of the user instead of remaining as art. What do i need to configure so that art group stays as the group id for that file? You need to set the set GID bit on the directory. This ensures that files created within it inherit the group of the directory, not the effective group id of the creating process. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] ACLs and Samba
Hallo can someone help me with the following problem? I have set a default ACL to the /home directory: # file: home # owner: root # group: root user::rwx group::rwx other::r-x default:user::rwx default:user:root:rwx default:group::rwx default:group:root:rwx default:group:users:rwx default:mask::rwx default:other::r-x When Windows clients access a subdirectory the following happens: An Excel file is created showing the following permissions. -rwxrwxr-x+ 1 owner users 13824 2005-02-25 10:20 Test-110.xls OK so far. when I reopen the file and try to save the changes I get an error message from Excel and the permissions of the file changes to: -r-xrwxr-x+ 1 owner users 13824 2005-02-25 10:20 Test-110.xls the smb.conf entry for the share is [db] comment = Datenbank path = /home/db read only = No create mask = 0777 directory mask = 0777 inherit permissions = Yes oplocks = No inherit acls = Yes strict locking = no Also access shows the same behaviour. Word and other programs like notepad work well as expected. I´m working with SuSE 9.2 (Samba3.0.9) What´s wrong? Harry -- Dr. Harry Knitter Hans-Herold-Str. 20 D-95326 Kulmbach Tel. 09221-97663 Fax. 09221-97664 [EMAIL PROTECTED] gpg key-ID 8A0657DB Fingerprint AE7B 61F1 ACC2 5944 A29A 8C31 2D12 2190 8A06 57DB pgpFHlM73kvDn.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] ACLs and samba
Hi, I'm having trouble getting ACLs and samba to work on solaris. In a unix shell I can set and get the ACLs with setfacl and getfacl just fine. Connecting with a window machine (w2000/w2003) to samba lets me list the ACLs and even modify them. The problem is creating new ACLs. In the logs I get 20031029/local2.error:Oct 29 16:30:11 test1 smbd[5417]: [ID 702911 local2.error] create_canon_ace_lists: unable to map SID S-1-5-21-3959417778-1711865379-3952174976-20920 to uid or gid. Seems to me there is a problem mapping from Windows SIDs to Unix uid. Reading the documentation, winbind seems to be the only solution to this problem. But I don't wish to use winbind as I allready have syncronized accounts on both windows and unix. Though looking at the code it seems to me that this is the only option available. Any ideas? -- Marius Grannæs -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs and samba
Marius Grannæs: Hi, I'm having trouble getting ACLs and samba to work on solaris. In a unix shell I can set and get the ACLs with setfacl and getfacl just fine. Connecting with a window machine (w2000/w2003) to samba lets me list the ACLs and even modify them. The problem is creating new ACLs. In the logs I get 20031029/local2.error:Oct 29 16:30:11 test1 smbd[5417]: [ID 702911 local2.error] create_canon_ace_lists: unable to map SID S-1-5-21-3959417778-1711865379-3952174976-20920 to uid or gid. Seems to me there is a problem mapping from Windows SIDs to Unix uid. Reading the documentation, winbind seems to be the only solution to this problem. But I don't wish to use winbind as I allready have syncronized accounts on both windows and unix. Though looking at the code it seems to me that this is the only option available. Any ideas? Some more information: I'm running samba 3.0.0 with the following setup: security = domain nt acl support = yes -- Marius Grannæs I see fragged people. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs and samba
On Tue, 18 Nov 2003, Marius [iso-8859-1] Grannæs wrote: Marius Grannæs: Hi, I'm having trouble getting ACLs and samba to work on solaris. In a unix shell I can set and get the ACLs with setfacl and getfacl just fine. Connecting with a window machine (w2000/w2003) to samba lets me list the ACLs and even modify them. The problem is creating new ACLs. In the logs I get 20031029/local2.error:Oct 29 16:30:11 test1 smbd[5417]: [ID 702911 local2.error] create_canon_ace_lists: unable to map SID S-1-5-21-3959417778-1711865379-3952174976-20920 to uid or gid. Seems to me there is a problem mapping from Windows SIDs to Unix uid. Reading the documentation, winbind seems to be the only solution to this problem. But I don't wish to use winbind as I allready have syncronized accounts on both windows and unix. Though looking at the code it seems to me that this is the only option available. Any ideas? Some more information: I'm running samba 3.0.0 with the following setup: security = domain nt acl support = yes You will need to use current CVS samba-3.0.1pre3. Suggest you add to smb.conf [globals]: winbind trusted domains only = Yes Then run winbindd. This was added to solve the problem you are seeing. - John T. -- John H Terpstra Email: [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs and samba
John H Terpstra: On Tue, 18 Nov 2003, Marius [iso-8859-1] Grannæs wrote: Marius Grannæs: Hi, I'm having trouble getting ACLs and samba to work on solaris. In a unix shell I can set and get the ACLs with setfacl and getfacl just fine. Connecting with a window machine (w2000/w2003) to samba lets me list the ACLs and even modify them. The problem is creating new ACLs. In the logs I get 20031029/local2.error:Oct 29 16:30:11 test1 smbd[5417]: [ID 702911 local2.error] create_canon_ace_lists: unable to map SID S-1-5-21-3959417778-1711865379-3952174976-20920 to uid or gid. Seems to me there is a problem mapping from Windows SIDs to Unix uid. Reading the documentation, winbind seems to be the only solution to this problem. But I don't wish to use winbind as I allready have syncronized accounts on both windows and unix. Though looking at the code it seems to me that this is the only option available. Any ideas? Some more information: I'm running samba 3.0.0 with the following setup: security = domain nt acl support = yes You will need to use current CVS samba-3.0.1pre3. Suggest you add to smb.conf [globals]: winbind trusted domains only = Yes Then run winbindd. This was added to solve the problem you are seeing. Thanks! This is just what I wanted :-). I've been pulling my hair for days over this. Is this in the documentation somewhere? Again, many thanks =) -- Marius Grannæs -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs and samba
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Grannæs wrote: |Suggest you add to smb.conf [globals]: | | winbind trusted domains only = Yes | |Then run winbindd. This was added to solve the problem you are seeing. | | | Thanks! This is just what I wanted :-). I've been pulling | my hair for days over this. Is this in the documentation | somewhere? from smb.conf(5) ~ winbind trusted domains only (G) ~ This parameter is designed to allow Samba servers ~ that are members of a Samba controlled domain to ~ use UNIX accounts distributed via NIS, rsync, or ~ LDAP as the uid's for winbindd users in the hosts ~ primary domain. Therefore, the user 'SAMBA\user1' ~ would be mapped to the account 'user1' in ~ /etc/passwd instead of allocating a new uid for him ~ or her. ~ Default: winbind trusted domains only = no - -- cheers, jerry - -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc If we're adding to the noise, turn off this song --Switchfoot (2003) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/ul9DIR7qMdg1EfYRAgr6AJ9HHXIHZOfTKXlmo70tVXQfkLZLtwCfbdrR s8jtUP8Lo1MGwzBhOJP5xGM= =KK46 -END PGP SIGNATURE- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs and samba
On Tue, Nov 18, 2003 at 06:30:13PM +0100, Marius Grannæs wrote:
John H Terpstra:
On Tue, 18 Nov 2003, Marius [iso-8859-1] Grannæs wrote:
Marius Grannæs:
Hi,
I'm having trouble getting ACLs and samba to work on solaris. In a unix
shell I can set and get the ACLs with setfacl and getfacl just fine.
Connecting with a window machine (w2000/w2003) to samba lets me
list the ACLs and even modify them. The problem is creating new
ACLs. In the logs I get
20031029/local2.error:Oct 29 16:30:11 test1 smbd[5417]: [ID 702911
local2.error] create_canon_ace_lists: unable to map SID
S-1-5-21-3959417778-1711865379-3952174976-20920 to uid or gid.
Seems to me there is a problem mapping from Windows SIDs to Unix uid. Reading
the documentation, winbind seems to be the only solution to this problem.
But I don't wish to use winbind as I allready have syncronized accounts
on both windows and unix. Though looking at the code it seems to me
that this is the only option available.
Any ideas?
Some more information:
I'm running samba 3.0.0 with the following setup:
security = domain
nt acl support = yes
You will need to use current CVS samba-3.0.1pre3.
Suggest you add to smb.conf [globals]:
winbind trusted domains only = Yes
Then run winbindd. This was added to solve the problem you are seeing.
Thanks! This is just what I wanted :-). I've been pulling my hair for days
over this. Is this in the documentation somewhere?
Again, many thanks =)
--
Marius Grannæs
I had the some problem at my site too. I noticed that I got the correct user
when I used the tool wbinfo to search for a SID or for a username. However,
all other queries gave me the wrong result.
My solution was a quick hack to wb_client.c to make it work. The hack was
simply to let samba always search by name and then use getpw* and getgr*
functions to get the uid/gid I wanted. I included the patch below...
So this is now done/fixed/whatever in samba 3.0.1? So you can run winbindd
without having to specify a uid/gid range and it will directly read the info
from the system without trying to use its own uid/gid mapper? If it is, then
I'm really looking forward to the release! :)
- edvard
--- wb_client.c.orig2003-08-21 19:41:32.0 +0300
+++ wb_client.c 2003-08-21 19:42:52.0 +0300
@@ -110,6 +110,9 @@
int result;
fstring sid_str;
+ /* Edu: added */
+ struct passwd *pw;
+
if (!puid)
return False;
@@ -120,10 +123,15 @@
sid_to_string(sid_str, sid);
fstrcpy(request.data.sid, sid_str);
-
- /* Make request */
- result = winbindd_request(WINBINDD_SID_TO_UID, request, response);
+ /* Make request - Edu: changed to lookup by name */
+ if((result = winbindd_request(WINBINDD_LOOKUPSID, request, response)) ==
NSS_STATUS_SUCCESS) {
+ pw = sys_getpwnam(response.data.name.name);
+ if(pw != NULL) {
+ DEBUG(10,(winbind_sid_to_uid: searched by name: found uid %d
for SID %s\n, pw-pw_uid, sid_str));
+ response.data.uid = pw-pw_uid;
+ }
+ }
/* Copy out result */
@@ -140,8 +148,12 @@
{
struct winbindd_request request;
struct winbindd_response response;
+ struct passwd *pw;
int result;
+ /* Edu: added */
+ fstring domain;
+
if (!sid)
return False;
@@ -156,6 +168,18 @@
result = winbindd_request(WINBINDD_UID_TO_SID, request, response);
+ /* Edu: There might not be a map, so try by name */
+ if(result != NSS_STATUS_SUCCESS) {
+ pw = sys_getpwuid(uid);
+ if(pw != NULL) {
+ fstrcpy(request.data.name.name, pw-pw_name);
+ fstrcpy(request.data.name.dom_name, lp_workgroup());
+ if((result = winbindd_request(WINBINDD_LOOKUPNAME, request,
response)) == NSS_STATUS_SUCCESS) {
+ DEBUG(0,((winbind_uid_to_sid: searched by name: found
SID %s for uid %d\n), response.data.sid.sid, uid));
+ }
+ }
+ }
+
/* Copy out result */
if (result == NSS_STATUS_SUCCESS) {
@@ -177,6 +201,9 @@
int result;
fstring sid_str;
+ /* Edu: added */
+ struct group *gr;
+
if (!pgid)
return False;
@@ -188,9 +215,14 @@
sid_to_string(sid_str, sid);
fstrcpy(request.data.sid, sid_str);
- /* Make request */
-
- result = winbindd_request(WINBINDD_SID_TO_GID, request, response);
+ /* Make request - Edu: changed to lookup by name */
+ if((result = winbindd_request(WINBINDD_LOOKUPSID, request, response)) ==
NSS_STATUS_SUCCESS) {
+ gr = sys_getgrnam(response.data.name.name
RE: [Samba] ACLs with samba
You were right on the --with-acl not being compiled. The problem now is that once we got acl-dev installed, samba won't compile at all. Is there anyone out there using ACLs under Debian Woody and if so, would you please tell us what versions of the various ACL/ATTR/fileutils packages you are using? We have tried with the woody versions of attr/acl (2.0.8) and also rolling our own packages from the latest greatest at bestbits. When trying to compile using the woody versions, configure would not detect the acl binaries, when compiling from the latest bestbits, we got a bunch of ugly stuff like this: include/vfs.h:111: parse error before acl_t include/vfs.h:112: parse error before acl_entry_t include/vfs.h:113: parse error before acl_entry_t include/vfs.h:114: parse error before acl_entry_t include/vfs.h:115: warning: no semicolon at end of struct or union include/vfs.h:116: parse error before '*' token Any input would be greatly appreciated-we have tried both samba 2.2.6 and 2.2.7 and are running out of ideas... Tom On Thu, 21 Nov 2002 16:07:08 -0500 Tom Hallewell [EMAIL PROTECTED] wrote: 1. I am unable to alter permissions from Win2K clients using the Properties-Security interface. Is this normal? I get the Unable to save Permission Changes on new Folder. Access is denied. message. This occurs with all accounts, both privileged and unprivileged. Are you sure you compiled Samba with ACL support? `ldd /path-to-your/smbd` should show libacl.so.1 in it's list. Even when giving the option --with-acl it's possible it didn't compile with ACL support due to the perhaps not installed dev-package acl-dev (which is available as DEB-package). So long, Max -- The first time any man's freedom is trodden on, we're all damaged. Cpt. Picard, The Drumhead, StarTrek TNG http://homex.subnet.at/~max/ -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs with samba
On Mon, 25 Nov 2002 19:56:49 -0500 Tom Hallewell [EMAIL PROTECTED] wrote: Hi! The problem now is that once we got acl-dev installed, samba won't compile at all. Is there anyone out there using ACLs under Debian Woody and if so, would you please tell us what versions of the various ACL/ATTR/fileutils packages you are using? [...] got a bunch of ugly stuff like this: include/vfs.h:111: parse error before acl_t [...] Any input would be greatly appreciated-we have tried both samba 2.2.6 and 2.2.7 and are running out of ideas... Hmmm... Sorry, I'll probabely be of little help on this one. I used Woody as it is (all packages including the Samba source package (Samba version 2.2.3a) which compiled and worked flawlessly). Here is what I did to get XFS and Samba with ACLs working: http://homex.subnet.at/~max/comp-12_xfs.php So long, Max -- The first time any man's freedom is trodden on, we're all damaged. Cpt. Picard, The Drumhead, StarTrek TNG http://homex.subnet.at/~max/ -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
RE: [Samba] ACLs with samba
Only the owner of a file/directory can alter the permissions through the Windoze client. If you want to be able to change everyone's ACLs then create a special admin share with 'force user = root' and this will ensure that, as root, you can do anything to anything (dangerous so make sure you don't let anyone else near the share!). Noel -Original Message- From: Mikko Rautiainen [mailto:[EMAIL PROTECTED]] Sent: 22 November 2002 08:58 To: [EMAIL PROTECTED] Cc: Samba ML Subject: Re: [Samba] ACLs with samba Hi, What filesystem are you using? Like ReiserFS doesn't support ACL's but ext3 and XFS does. And is your PDC a win??? or is it a samba PDC? I have a win2k PDC and samba fileserver and I use Winbind to authenticate. I can change the permissions for files and folders in the PDC or on my desktop. I didn't use any force create modes. Mikko Rautiainen Tom Hallewell wrote: Hi- I am experiencing some odd behavior with ACLs with winbindd using Samba 2.6 on Debian Woody (kernel version 2.4.18). 1. I am unable to alter permissions from Win2K clients using the Properties-Security interface. Is this normal? I get the Unable to save Permission Changes on new Folder. Access is denied. message. This occurs with all accounts, both privileged and unprivileged. 2. Permissions set using setfacl -m u:DOMAIN\USER:rwx alter the permissions just fine, but do not show up in the Properties-Security interface. If I run chmod DOMAIN\USER.DOMAIN\USER it shows up. The permissions show up correctly if a file or directory is created on the share from a Win client, but cannot be modified once created, and the ACL info is not seen. Is this behavior normal, or am I doing something wrong? Here is the relevant section of smb.conf: [SHARE] comment = Blah blah path = /usr/tmp/share valid users = @DOMAIN\Group1 @DOMAIN\Group2 public = no writable = yes printable = no create mask = 0770 directory mode = 0770 force create mode = 0770 force directory mode = 0770 Here is the output from getfacl /usr/tmp/share getfacl: Removing leading '/' from absolute path names # file: usr/tmp/BUR # owner: mpgmover # group: mpgmover user::rwx group::rwx group:DOMAIN\Group1:rwx group:DOMAIN\Group2:rwx mask::rwx other::--- Any input would be appreciated. Thanks Tom Hallewell Radio Free Asia Washington DC -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] ACLs with samba
Hi- I am experiencing some odd behavior with ACLs with winbindd using Samba 2.6 on Debian Woody (kernel version 2.4.18). 1. I am unable to alter permissions from Win2K clients using the Properties-Security interface. Is this normal? I get the Unable to save Permission Changes on new Folder. Access is denied. message. This occurs with all accounts, both privileged and unprivileged. 2. Permissions set using setfacl -m u:DOMAIN\USER:rwx alter the permissions just fine, but do not show up in the Properties-Security interface. If I run chmod DOMAIN\USER.DOMAIN\USER it shows up. The permissions show up correctly if a file or directory is created on the share from a Win client, but cannot be modified once created, and the ACL info is not seen. Is this behavior normal, or am I doing something wrong? Here is the relevant section of smb.conf: [SHARE] comment = Blah blah path = /usr/tmp/share valid users = @DOMAIN\Group1 @DOMAIN\Group2 public = no writable = yes printable = no create mask = 0770 directory mode = 0770 force create mode = 0770 force directory mode = 0770 Here is the output from getfacl /usr/tmp/share getfacl: Removing leading '/' from absolute path names # file: usr/tmp/BUR # owner: mpgmover # group: mpgmover user::rwx group::rwx group:DOMAIN\Group1:rwx group:DOMAIN\Group2:rwx mask::rwx other::--- Any input would be appreciated. Thanks Tom Hallewell Radio Free Asia Washington DC -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACLs with samba
On Thu, 21 Nov 2002 16:07:08 -0500 Tom Hallewell [EMAIL PROTECTED] wrote: 1. I am unable to alter permissions from Win2K clients using the Properties-Security interface. Is this normal? I get the Unable to save Permission Changes on new Folder. Access is denied. message. This occurs with all accounts, both privileged and unprivileged. Are you sure you compiled Samba with ACL support? `ldd /path-to-your/smbd` should show libacl.so.1 in it's list. Even when giving the option --with-acl it's possible it didn't compile with ACL support due to the perhaps not installed dev-package acl-dev (which is available as DEB-package). So long, Max -- The first time any man's freedom is trodden on, we're all damaged. Cpt. Picard, The Drumhead, StarTrek TNG http://homex.subnet.at/~max/ -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
