Re: [Samba] Samba ACL bug?
Hi,jerry. How are you? Afterwards, I kept investigating. This problem doesn't occur in the ext3 filesystem. (This problem occurs by the vxfs filesystem. ) There are some questions. Q1.Does not Samba correspond to VxFS? Q2.Does the program that sets ACL have the difference by the filesystem? - Original Message - From: Gerald (Jerry) Carter [EMAIL PROTECTED] To: H.Kitagawa [EMAIL PROTECTED] Cc: samba@lists.samba.org Sent: Tuesday, January 30, 2007 2:05 PM Subject: Re: [Samba] Samba ACL bug? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiro, [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx mask::rwx mask::rwx other::--- Any idea why the mask listed twice here. What file system is this? default:user::rwx default:group::rwx default:group:[EMAIL PROTECTED]:rwx default:mask::rwx default:other::--- Then, the member of the Domain Users group became inaccessible the folder. The default aces are not used to determine access to a folder. Only for files and subfolders created within the directory. So that shouldn't make any difference. I would suggest looking at a level 10 debug log from smbd and seeing the root cause of the ACCESS_DENIED error. cheers, jerry = Samba--- http://www.samba.org Centeris --- http://www.centeris.com What man is a man who does not make the world better? --Balian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvtIrIR7qMdg1EfYRAk1HAJ4wN/V2dOtksgEDGoVKZhdCNHMyegCgrxFF gWbdDPOh+8JwxrxRBtPt3oA= =MRuR -END PGP SIGNATURE- ＊ Hironori Kitagawa E-Mail: [EMAIL PROTECTED] ＊ -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Samba ACL bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiro, [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx mask::rwx mask::rwx other::--- Any idea why the mask listed twice here. What file system is this? default:user::rwx default:group::rwx default:group:[EMAIL PROTECTED]:rwx default:mask::rwx default:other::--- Then, the member of the Domain Users group became inaccessible the folder. The default aces are not used to determine access to a folder. Only for files and subfolders created within the directory. So that shouldn't make any difference. I would suggest looking at a level 10 debug log from smbd and seeing the root cause of the ACCESS_DENIED error. cheers, jerry = Samba--- http://www.samba.org Centeris --- http://www.centeris.com What man is a man who does not make the world better? --Balian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvtIrIR7qMdg1EfYRAk1HAJ4wN/V2dOtksgEDGoVKZhdCNHMyegCgrxFF gWbdDPOh+8JwxrxRBtPt3oA= =MRuR -END 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] Samba ACL bug?
Hi Jerrry - Original Message - From: Gerald (Jerry) Carter [EMAIL PROTECTED] To: H.Kitagawa [EMAIL PROTECTED] Cc: samba@lists.samba.org Sent: Tuesday, January 30, 2007 2:05 PM Subject: Re: [Samba] Samba ACL bug? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiro, [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx mask::rwx mask::rwx other::--- Any idea why the mask listed twice here. I do not understand the reason why the mask is listed two times. What file system is this? We are using vxfs(VERITAS). default:user::rwx default:group::rwx default:group:[EMAIL PROTECTED]:rwx default:mask::rwx default:other::--- Then, the member of the Domain Users group became inaccessible the folder. The default aces are not used to determine access to a folder. Only for files and subfolders created within the directory. So that shouldn't make any difference. I would suggest looking at a level 10 debug log from smbd and seeing the root cause of the ACCESS_DENIED error. I gathered the log with leve10. LOG1. It is a log when accessing it from the this server. [EMAIL PROTECTED] pub]# smbclient '//sambaSV/SMBpublic' -U fjsv003 Password: Domain=[KITA] OS=[Unix] Server=[Samba 3.0.21b-2] smb: \ cd testfolder smb: \testfolder\ ls NT_STATUS_ACCESS_DENIED listing \testfolder\* [2007/01/30 14:55:59, 5] smbd/uid.c:change_to_user(309) change_to_user uid=(10002,10002) gid=(0,1) [2007/01/30 14:55:59, 3] smbd/trans2.c:call_trans2findfirst(1632) call_trans2findfirst: dirtype = 16, maxentries = 1366, close_after_first=0, close_if_end = 2 requires_resume_key = 4 l evel = 0x104, max_data_bytes = 16644 [2007/01/30 14:55:59, 5] smbd/filename.c:unix_convert(108) unix_convert called on file testfolder/* [2007/01/30 14:55:59, 10] smbd/statcache.c:stat_cache_lookup(215) stat_cache_lookup: lookup failed for name [TESTFOLDER/*] [2007/01/30 14:55:59, 10] smbd/statcache.c:stat_cache_lookup(248) stat_cache_lookup: lookup succeeded for name [TESTFOLDER] - [testfolder] [2007/01/30 14:55:59, 5] smbd/filename.c:unix_convert(185) unix_convert begin: name = testfolder/*, dirpath = testfolder, start = * [2007/01/30 14:55:59, 10] smbd/mangle_hash2.c:is_mangled(276) is_mangled * ? [2007/01/30 14:55:59, 10] smbd/mangle_hash2.c:is_mangled_component(215) is_mangled_component * (len 1) ? [2007/01/30 14:55:59, 10] smbd/mangle_hash2.c:is_mangled(276) is_mangled * ? [2007/01/30 14:55:59, 10] smbd/mangle_hash2.c:is_mangled_component(215) is_mangled_component * (len 1) ? [2007/01/30 14:55:59, 5] smbd/filename.c:unix_convert(335) New file * [2007/01/30 14:55:59, 5] smbd/trans2.c:call_trans2findfirst(1688) dir=testfolder, mask = * [2007/01/30 14:55:59, 5] smbd/dir.c:dptr_create(391) dptr_create dir=testfolder [2007/01/30 14:55:59, 5] smbd/dir.c:OpenDir(1033) OpenDir: Can't open testfolder. Permission denied 2007/01/30 14:55:59, 3] smbd/error.c:unix_error_packet(90) unix_error_packet: error string = Permission denied [2007/01/30 14:55:59, 3] smbd/error.c:error_packet(146) error packet at smbd/trans2.c(1742) cmd=50 (SMBtrans2) NT_STATUS_ACCESS_DENIED LOG2. This is a log when accessing it from the Windows client. [2007/01/30 15:03:33, 3] smbd/process.c:switch_message(993) switch message SMBntcreateX (pid 6872) conn 0xa06d258 [2007/01/30 15:03:33, 4] smbd/uid.c:change_to_user(222) change_to_user: Skipping user change - already user [2007/01/30 15:03:33, 10] smbd/nttrans.c:reply_ntcreate_and_X(506) reply_ntcreateX: flags = 0x16, access_mask = 0x20089 file_attributes = 0x80, share_access = 0x7, create_disposition = 0x1 create_options = 0x0 root_dir_fid = 0x0 [2007/01/30 15:03:33, 5] smbd/filename.c:unix_convert(108) unix_convert called on file testfolder [2007/01/30 15:03:33, 10] smbd/statcache.c:stat_cache_lookup(248) stat_cache_lookup: lookup succeeded for name [TESTFOLDER] - [testfolder] [2007/01/30 15:03:33, 2] smbd/dosmode.c:unix_mode(70) unix_mode(testfolder) inheriting from . [2007/01/30 15:03:33, 2] smbd/dosmode.c:unix_mode(78) unix_mode(testfolder) inherit mode 40770 [2007/01/30 15:03:33, 3] smbd/dosmode.c:unix_mode(121) unix_mode(testfolder) returning 0760 [2007/01/30 15:03:33, 10] smbd/open.c:open_file_ntcreate(1110) open_file_ntcreate: fname=testfolder, dos_attrs=0x80 access_mask=0x20089 share_access=0x7 create_disposition = 0x1 cre ate_options=0x0 unix mode=0760 oplock_request=3 [2007/01/30 15:03:33, 8] smbd/dosmode.c:dos_mode(300) dos_mode: testfolder [2007/01/30 15:03:33, 8] smbd/dosmode.c:dos_mode_from_sbuf(167) dos_mode_from_sbuf returning d [2007/01/30 15:03:33, 8] smbd/dosmode.c:dos_mode(334) dos_mode returning d [2007/01/30 15:03:33, 10] smbd/open.c:open_file_ntcreate(1278) open_file_ntcreate: fname=testfolder, after mapping access_mask=0x20089 [2007/01/30 15:03:33, 5] smbd/files.c:file_new(128) allocated file structure 537, fnum = 4633 (2 used
[Samba] Samba ACL bug?
Hello, My name is Hiro. I'm using samba 3.0.21b-2(acl) and RHEL4.1(kernel 2.6.9-11.ELsmp) + AD Server Following problem: When the attribute of the group of the folder was set to a full control twice, the member of the group became inaccessible. I want to know this problem is BUG or SPEC. One example [smb.conf] security = ADS acl check permissions = no acl group control = no acl map full control = yes inherit acls = yes [User] [EMAIL PROTECTED] [uid=1([EMAIL PROTECTED]) gid=1([EMAIL PROTECTED] users) groups=1([EMAIL PROTECTED] users)] [EMAIL PROTECTED] [uid=10002([EMAIL PROTECTED]) gid=1([EMAIL PROTECTED] users) groups=1([EMAIL PROTECTED] users)] STEP1.The folder was made by using the Explorer of Windows. ACL state is as follows. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx group::rwx other::--- STEP2.The folder attribute is changed from the security tab. Domain Users(KITA\Domain Users) →full control checked and execute. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx group::rwx mask::rwx other::--- default:user::rwx default:group::rwx default:other::--- At this point, the member of the Domain Users group can access the testfolder. STEP3.The folder attribute is changed again. Domain Users(KITA\Domain Users) →full control checked and execute. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx mask::rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:[EMAIL PROTECTED]:rwx default:mask::rwx default:other::--- Then, the member of the Domain Users group became inaccessible the folder. [EMAIL PROTECTED] pub]# smbclient '//sambaSV/SMBpublic' -U fjsv003 Password: Domain=[KITA] OS=[Unix] Server=[Samba 3.0.21b-2] smb: \ cd testfolder smb: \testfolder\ ls NT_STATUS_ACCESS_DENIED listing \testfolder\* 32768 blocks of size 131072. 30551 blocks available smb: \testfolder\ cd .. *** Hironori KITAGAWA Japan *** -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Samba ACL bug?
Hello, My name is Hiro. I'm using samba 3.0.21b-2(acl) and RHEL4.1(kernel 2.6.9-11.ELsmp) + AD Server Following problem: When the attribute of the group of the folder was set to a full control twice, the member of the group became inaccessible. I want to know this problem is BUG or SPEC. One example [smb.conf] security = ADS acl check permissions = no acl group control = no acl map full control = yes inherit acls = yes [User] [EMAIL PROTECTED] [uid=1([EMAIL PROTECTED]) gid=1([EMAIL PROTECTED] users) groups=1([EMAIL PROTECTED] users)] [EMAIL PROTECTED] [uid=10002([EMAIL PROTECTED]) gid=1([EMAIL PROTECTED] users) groups=1([EMAIL PROTECTED] users)] STEP1.The folder was made by using the Explorer of Windows. ACL state is as follows. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx group::rwx other::--- STEP2.The folder attribute is changed from the security tab. Domain Users(KITA\Domain Users) →full control checked and execute. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx group::rwx mask::rwx other::--- default:user::rwx default:group::rwx default:other::--- At this point, the member of the Domain Users group can access the testfolder. STEP3.The folder attribute is changed again. Domain Users(KITA\Domain Users) →full control checked and execute. [EMAIL PROTECTED] pub]# getfacl testfolder # file: testfolder # owner: [EMAIL PROTECTED] # group: [EMAIL PROTECTED] user::rwx mask::rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:[EMAIL PROTECTED]:rwx default:mask::rwx default:other::--- Then, the member of the Domain Users group became inaccessible the folder. [EMAIL PROTECTED] pub]# smbclient '//sambaSV/SMBpublic' -U fjsv003 Password: Domain=[KITA] OS=[Unix] Server=[Samba 3.0.21b-2] smb: \ cd testfolder smb: \testfolder\ ls NT_STATUS_ACCESS_DENIED listing \testfolder\* 32768 blocks of size 131072. 30551 blocks available smb: \testfolder\ cd .. *** Hironori KITAGAWA Japan *** -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACL bug
hi damn! i'm going crazy... files created in the shell (bash) also get -x'ed example again: humanpdc:~ # getfacl /data/test/home/ getfacl: Removing leading '/' from absolute path names # file: data/test/home # owner: test # group: users user::rwx group::--- other::--- default:user::rwx default:group::--- default:mask::rwx default:other::--- humanpdc:~ # touch /data/test/home/test humanpdc:~ # getfacl /data/test/home/test getfacl: Removing leading '/' from absolute path names # file: data/test/home/test # owner: root # group: rootgroup user::rw- group::--- mask::rw- other::--- *argh* what's this? can anybody help me although it's not really smb related? thx³ Dariush Forouher schrieb: On Fri, 13 Feb 2004, Michael Gasch wrote: unfortunately this was not the problem though :( No, I think so as well. The umask setting only can take away permission bits, but it can't set new ones. Beside of that AFAIK Samba doesn't use an umask setting inherited from the parent process (and even if it would certenly be overwritten by the create mask setting). The problem I observed happens when creating files through Samba. Creating files from native Linux works (at least here) exactly as I'm expecting it to work. with attention to default:user::rwx why is it automatically set? AFAIK this is the default behaviour of the ACL implementation of Linux. The first time when setfacl is used these three defaults ACEs are automatically added with the same permissions of their non-default peers. and of course: on any file created in install owner just gets rw-, but my mask isn't recalculated (which is fine) Not for me! I don't like it if ordinary files have the x-bit set, which will happen if mask isn't shortened to rw-, like Samba does it at the moment! ciao Dariush -- Matrix - more than a vision ** Michael Gasch - Central IT Department - Max Planck Institute for Evolutionary Anthropology Deutscher Platz 6 04103 Leipzig Germany ** -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACL bug
so, i think i found an explanation: touch relies on mode parameter of creat(2), which is by default 666 this explains the behaviour of recalculating the mask and setting user:: to rw- anybody an idea how to change the default mode of 666 (kind of diabolic *gg) greez Michael Gasch schrieb: hi damn! i'm going crazy... files created in the shell (bash) also get -x'ed example again: humanpdc:~ # getfacl /data/test/home/ getfacl: Removing leading '/' from absolute path names # file: data/test/home # owner: test # group: users user::rwx group::--- other::--- default:user::rwx default:group::--- default:mask::rwx default:other::--- humanpdc:~ # touch /data/test/home/test humanpdc:~ # getfacl /data/test/home/test getfacl: Removing leading '/' from absolute path names # file: data/test/home/test # owner: root # group: rootgroup user::rw- group::--- mask::rw- other::--- *argh* what's this? can anybody help me although it's not really smb related? thx³ Dariush Forouher schrieb: On Fri, 13 Feb 2004, Michael Gasch wrote: unfortunately this was not the problem though :( No, I think so as well. The umask setting only can take away permission bits, but it can't set new ones. Beside of that AFAIK Samba doesn't use an umask setting inherited from the parent process (and even if it would certenly be overwritten by the create mask setting). The problem I observed happens when creating files through Samba. Creating files from native Linux works (at least here) exactly as I'm expecting it to work. with attention to default:user::rwx why is it automatically set? AFAIK this is the default behaviour of the ACL implementation of Linux. The first time when setfacl is used these three defaults ACEs are automatically added with the same permissions of their non-default peers. and of course: on any file created in install owner just gets rw-, but my mask isn't recalculated (which is fine) Not for me! I don't like it if ordinary files have the x-bit set, which will happen if mask isn't shortened to rw-, like Samba does it at the moment! ciao Dariush -- Matrix - more than a vision ** Michael Gasch - Central IT Department - Max Planck Institute for Evolutionary Anthropology Deutscher Platz 6 04103 Leipzig Germany ** -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACL bug
hi i experienced the same behaviour do you know whats the reason? i think its umask my umask tells me : 022 for rootthis changes the group setting, which is in this ACL case - yes you know - the effective mask greez Dariush Forouher schrieb: Hello, I'm using samba 3.0.2(acl) and kernel 2.4.24+acl, libacl-2.2.23. Following problem: When I create a file in an directory with extended ACLs, samba applies the create mask in a wrong way (IMHO). The normal behaviour of tools like chmod is that the second (middle) permission field is mapped to the mask ACE if the file has an extended ACL, so that the change applies to all groups. But Samba seems to set the group:: (Owning Group) ACE instead. This behaviour causes some minor problems, especially some users will see this file with x Bit set, when it shouldn't. One example: There is an directory called testdir: # file: testdir # owner: root # group: root user::rwx group::--- group:admins:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:admins:rwx default:mask::rwx default:other::--- The owning group or world shall never have access to this directory (and to all children), only members of group 'admins' shall have. Now if I create a file on the console, it has the following ACL: # file: testfile1 # owner: dariush # group: schueler user::rw- group::--- group:admins:rwx#effective:rw- mask::rw- other::--- You'll see that group:: is unchanged and mask:: has shortened to rw- Now a file that I've created through Samba: (create mask = 0660 or create mask = 0600; make no difference): # file: testdir/testfile2 # owner: dariush # group: schueler user::rw- group::rw- group:admins:rwx mask::rwx other::--- You see that mask:: is unchanged, while group:: has been changed instead incorrectly. So, in my eyes this looks like a bug. If it is not, it would be nice if someone could point me a way how to get the wanted behaviour somehow else. regards Dariush -- Matrix - more than a vision ** Michael Gasch - Central IT Department - Max Planck Institute for Evolutionary Anthropology Deutscher Platz 6 04103 Leipzig Germany ** -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACL bug
unfortunately this was not the problem though :( i found another problem ACL is humanpdc:/data/install # cat ~/acl # file: data/install # owner: root # group: rootgroup user::rwx user:gasch:rwx user:paul:rwx user:foedisch:rwx group::--- mask::rwx other::--- default:user:gasch:rwx default:user:paul:rwx default:user:foedisch:rwx default:group::--- default:mask::rwx default:other::--- but humanpdc:/data/install # cat ~/acl |setfacl --set-file=- ../install/ gives humanpdc:/data/install # getfacl ../install/ # file: ../install # owner: root # group: rootgroup user::rwx user:gasch:rwx user:paul:rwx user:foedisch:rwx group::--- mask::rwx other::--- default:user::rwx default:user:gasch:rwx default:user:paul:rwx default:user:foedisch:rwx default:group::--- default:mask::rwx default:other::--- with attention to default:user::rwx why is it automatically set? and of course: on any file created in install owner just gets rw-, but my mask isn't recalculated (which is fine) e.g. humanpdc:/data/install # touch test; getfacl test # file: test # owner: gasch # group: users user::rw- user:gasch:rwx user:paul:rwx user:foedisch:rwx group::--- mask::rwx other::--- create masks in samba are 0077 umask for user is 0077 but dirs are created/acl-ed correctly!!! lot's of ??? thx Michael Gasch schrieb: hi i experienced the same behaviour do you know whats the reason? i think its umask my umask tells me : 022 for rootthis changes the group setting, which is in this ACL case - yes you know - the effective mask greez Dariush Forouher schrieb: Hello, I'm using samba 3.0.2(acl) and kernel 2.4.24+acl, libacl-2.2.23. Following problem: When I create a file in an directory with extended ACLs, samba applies the create mask in a wrong way (IMHO). The normal behaviour of tools like chmod is that the second (middle) permission field is mapped to the mask ACE if the file has an extended ACL, so that the change applies to all groups. But Samba seems to set the group:: (Owning Group) ACE instead. This behaviour causes some minor problems, especially some users will see this file with x Bit set, when it shouldn't. One example: There is an directory called testdir: # file: testdir # owner: root # group: root user::rwx group::--- group:admins:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:admins:rwx default:mask::rwx default:other::--- The owning group or world shall never have access to this directory (and to all children), only members of group 'admins' shall have. Now if I create a file on the console, it has the following ACL: # file: testfile1 # owner: dariush # group: schueler user::rw- group::--- group:admins:rwx#effective:rw- mask::rw- other::--- You'll see that group:: is unchanged and mask:: has shortened to rw- Now a file that I've created through Samba: (create mask = 0660 or create mask = 0600; make no difference): # file: testdir/testfile2 # owner: dariush # group: schueler user::rw- group::rw- group:admins:rwx mask::rwx other::--- You see that mask:: is unchanged, while group:: has been changed instead incorrectly. So, in my eyes this looks like a bug. If it is not, it would be nice if someone could point me a way how to get the wanted behaviour somehow else. regards Dariush -- Matrix - more than a vision ** Michael Gasch - Central IT Department - Max Planck Institute for Evolutionary Anthropology Deutscher Platz 6 04103 Leipzig Germany ** -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: [Samba] ACL bug
On Fri, 13 Feb 2004, Michael Gasch wrote: unfortunately this was not the problem though :( No, I think so as well. The umask setting only can take away permission bits, but it can't set new ones. Beside of that AFAIK Samba doesn't use an umask setting inherited from the parent process (and even if it would certenly be overwritten by the create mask setting). The problem I observed happens when creating files through Samba. Creating files from native Linux works (at least here) exactly as I'm expecting it to work. with attention to default:user::rwx why is it automatically set? AFAIK this is the default behaviour of the ACL implementation of Linux. The first time when setfacl is used these three defaults ACEs are automatically added with the same permissions of their non-default peers. and of course: on any file created in install owner just gets rw-, but my mask isn't recalculated (which is fine) Not for me! I don't like it if ordinary files have the x-bit set, which will happen if mask isn't shortened to rw-, like Samba does it at the moment! ciao Dariush -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] ACL bug
Hello, I'm using samba 3.0.2(acl) and kernel 2.4.24+acl, libacl-2.2.23. Following problem: When I create a file in an directory with extended ACLs, samba applies the create mask in a wrong way (IMHO). The normal behaviour of tools like chmod is that the second (middle) permission field is mapped to the mask ACE if the file has an extended ACL, so that the change applies to all groups. But Samba seems to set the group:: (Owning Group) ACE instead. This behaviour causes some minor problems, especially some users will see this file with x Bit set, when it shouldn't. One example: There is an directory called testdir: # file: testdir # owner: root # group: root user::rwx group::--- group:admins:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:admins:rwx default:mask::rwx default:other::--- The owning group or world shall never have access to this directory (and to all children), only members of group 'admins' shall have. Now if I create a file on the console, it has the following ACL: # file: testfile1 # owner: dariush # group: schueler user::rw- group::--- group:admins:rwx#effective:rw- mask::rw- other::--- You'll see that group:: is unchanged and mask:: has shortened to rw- Now a file that I've created through Samba: (create mask = 0660 or create mask = 0600; make no difference): # file: testdir/testfile2 # owner: dariush # group: schueler user::rw- group::rw- group:admins:rwx mask::rwx other::--- You see that mask:: is unchanged, while group:: has been changed instead incorrectly. So, in my eyes this looks like a bug. If it is not, it would be nice if someone could point me a way how to get the wanted behaviour somehow else. regards Dariush -- PGP Fingerprint: 0x886C99A1 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] ACL bug FIXes for get_nt_acl()
Two attached patches for samba 2.2.7a and 3.0-alfa22, that I've made today, fix 3 bugs mentioned in my previous e-mail. 1) For each file in addition to ALLOW ACE proper DENY ACE is created. 2) Take ownership is shown DENIED for all except root ACEs 3) Read Permissions and read attributes are always shown as allowed, as they are actually allowed. -- Zhitomirsky Sergey. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] ACL bug FIXes for get_nt_acl() (resend)
It seems attached patches were lost, resending inline :
Two attached patches for samba 2.2.7a and 3.0-alfa22,
that I've made today, fix 3 bugs mentioned in my previous e-mail.
1) For each file in addition to ALLOW ACE
proper DENY ACE is created.
2) Take ownership is shown DENIED for all except root ACEs
3) Read Permissions and read attributes are always shown as allowed,
as they are actually allowed.
--
Zhitomirsky Sergey.
--- samba-3.0alpha22/source/smbd/posix_acls.c Mon Feb 24 18:12:33 2003
+++ samba-3.0alpha22-fixed/source/smbd/posix_acls.c Thu Mar 6 17:09:56 2003
-354,15 +354,19
not get. Deny entries are implicit on get with ace-perms = 0.
/
-static SEC_ACCESS map_canon_ace_perms(int *pacl_type, DOM_SID *powner_sid, canon_ace
*ace)
+static SEC_ACCESS map_canon_ace_perms(int *pacl_type, DOM_SID *powner_sid, canon_ace
*ace,
+ SEC_ACCESS* sa_deny, int *pacl_type_deny)
{
SEC_ACCESS sa;
uint32 nt_mask = 0;
-
- *pacl_type = SEC_ACE_TYPE_ACCESS_ALLOWED;
+ uint32 nt_mask_deny = 0;
+
+ *pacl_type = SEC_ACE_TYPE_ACCESS_ALLOWED;
+ *pacl_type_deny = SEC_ACE_TYPE_ACCESS_DENIED;
if ((ace-perms ALL_ACE_PERMS) == ALL_ACE_PERMS) {
- nt_mask = UNIX_ACCESS_RWX;
+ nt_mask = UNIX_ACCESS_RWX;
+ nt_mask_deny = WRITE_OWNER_ACCESS;
} else if ((ace-perms ALL_ACE_PERMS) == (mode_t)0) {
/*
* Windows NT refuses to display ACEs with no permissions in them (but
-377,15 +381,31
nt_mask = UNIX_ACCESS_NONE;
else
nt_mask = 0;
+
+ nt_mask_deny = UNIX_ACCESS_RWX;
+
} else {
nt_mask |= ((ace-perms S_IRUSR) ? UNIX_ACCESS_R : 0 );
nt_mask |= ((ace-perms S_IWUSR) ? UNIX_ACCESS_W : 0 );
nt_mask |= ((ace-perms S_IXUSR) ? UNIX_ACCESS_X : 0 );
+
+ nt_mask_deny = ~nt_mask UNIX_ACCESS_RWX;
}
- DEBUG(10,(map_canon_ace_perms: Mapped (UNIX) %x to (NT) %x\n,
- (unsigned int)ace-perms, (unsigned int)nt_mask ));
+ /* READ ACL Read Attributes afai see are always allowed in POSIX */
+ nt_mask_deny = ~( READ_CONTROL_ACCESS | FILE_READ_ATTRIBUTES);
+ nt_mask |= READ_CONTROL_ACCESS | FILE_READ_ATTRIBUTES;
+ /* workaround for take ownership for root's ACE */
+ if (ace-owner_type == UID_ACE !ace-unix_ug.uid) {
+ nt_mask_deny = ~WRITE_OWNER_ACCESS;
+ nt_mask |= WRITE_OWNER_ACCESS;//UNIX_ACCESS_NONE;
+ }
+
+ DEBUG(10,(map_canon_ace_perms: Mapped (UNIX) %x to (NT) %x ~%x\n,
+ (unsigned int)ace-perms, (unsigned int)nt_mask, (unsigned
int)nt_mask_deny));
+
+ init_sec_access(sa_deny, nt_mask_deny);
init_sec_access(sa,nt_mask);
return sa;
}
-2208,6 +2228,7
{
canon_ace *ace;
int nt_acl_type;
+ int nt_acl_type_deny;
int i;
if (nt4_compatible_acls()) {
-2292,12 +2313,12
num_dir_acls = count_canon_ace_list(dir_ace);
/* Allocate the ace list. */
- if ((nt_ace_list = (SEC_ACE *)malloc((num_acls + num_profile_acls +
num_dir_acls)* sizeof(SEC_ACE))) == NULL) {
+ if ((nt_ace_list = (SEC_ACE *)malloc((2 * num_acls + num_profile_acls
+ 2 * num_dir_acls)*sizeof(SEC_ACE))) == NULL) {
DEBUG(0,(get_nt_acl: Unable to malloc space for
nt_ace_list.\n));
goto done;
}
- memset(nt_ace_list, '\0', (num_acls + num_dir_acls) * sizeof(SEC_ACE)
);
+ memset(nt_ace_list, '\0', (num_acls + num_dir_acls) * 2 *
sizeof(SEC_ACE) );
/*
* Create the NT ACE list from the canonical ace lists.
-2307,8 +2328,10
for (i = 0; i num_acls; i++, ace = ace-next) {
SEC_ACCESS acc;
-
- acc = map_canon_ace_perms(nt_acl_type, owner_sid, ace );
+ SEC_ACCESS acc_deny;
+
+ acc = map_canon_ace_perms(nt_acl_type, owner_sid, ace ,
acc_deny, nt_acl_type_deny);
+ init_sec_ace(nt_ace_list[num_aces++], ace-trustee,
nt_acl_type_deny, acc_deny, 0);
init_sec_ace(nt_ace_list[num_aces++], ace-trustee,
nt_acl_type, acc, 0);
}
-2324,8 +2347,11
for (i = 0; i num_dir_acls; i++, ace = ace-next) {
SEC_ACCESS acc;
-
- acc = map_canon_ace_perms(nt_acl_type, owner_sid, ace );
+
