Hello, Not exactly samba but related to ntfs acls, so hope do not get flamed! Recently I am seeing a response to get security descriptor query to Windows server as Malformed Packet in wireshark trace and the number of aces in the dacl in big endian format. I thought all the data over the wire was in little endian format! I have seen this on Windows XP and Windows Server 2003. Have not intentionally installed any patches on either. This is causing grief to linux cifs client in acl code, when I parse the dacl, suddenly now the number of aces is a huge number instead of two or three or so aces and that is causing oopses in kmalloc'ing. I know this was not a problem earlier this year or late last year. Regards, Shirish
On 2/7/08, Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:> Hello, > > Not exactly samba but related to ntfs acls, so hope do not get flamed! > > Recently I am seeing a response to get security descriptor query to Windows > server as Malformed Packet in wireshark trace and the number of aces > in the dacl in > big endian format. I thought all the data over the wire was in little > endian format! > > I have seen this on Windows XP and Windows Server 2003. > Have not intentionally installed any patches on either. > > This is causing grief to linux cifs client in acl code, when I parse the dacl, > suddenly now the number of aces is a huge number instead of two or three or > so aces and that is causing oopses in kmalloc'ing. > > I know this was not a problem earlier this year or late last year. > > Regards, > > Shirish >smbcacls works fine, I see number of aces in little endian format. Must be something linux cifs client that is doing? But why just number of aces?
> ... I thought all the data over the wire was in > little endian format! ...Huh? Ever since the original ARPAnet network data (possibly except Microsoft) has been in BIGendian format. See for example http://www.ietf.org/rfc/ien/ien137.txt for details. It's easy to get the impression the native numeric order of the Intel chip is "correct"; more likely it's a horrid hack inherited from the micro world via the Z80. thanks! -Chuck Kollars ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
On 2/7/08, Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:> On 2/7/08, Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote: > > Hello, > > > > Not exactly samba but related to ntfs acls, so hope do not get flamed! > > > > Recently I am seeing a response to get security descriptor query to Windows > > server as Malformed Packet in wireshark trace and the number of aces > > in the dacl in > > big endian format. I thought all the data over the wire was in little > > endian format! > > > > I have seen this on Windows XP and Windows Server 2003. > > Have not intentionally installed any patches on either. > > > > This is causing grief to linux cifs client in acl code, when I parse the dacl, > > suddenly now the number of aces is a huge number instead of two or three or > > so aces and that is causing oopses in kmalloc'ing. > > > > I know this was not a problem earlier this year or late last year. > > > > Regards, > > > > Shirish > > > > I am posting the wireshark traces, one from the cifs client and one > from smbcacls > command, both containing response for NT Query Security Descriptor request > Malformed Packet (with big-endian coded number of aces field in the > DACL) response > for cifs client and correct response for smbcacl command, to the same > Windows XP server and same share on that server. > > I looked for pertinent data on Microsoft Knowledgebase but did not get any hits. > > Any pointers on how to debug this are so much appreciated. > > Regards, > > Shirish > >Yes, it is the bug in cifs client code. When setting dacl during chmod, number of aces was not sent in little endian format. So the wrong value stayed stuck with the server. Working on (one line) fix. Regards, Shirish