ntacl and upgradeprovision patches

[Matthieu Patou]

Hello,

So I found the reason of the problem on x64:
I did in my python binding as in generated python binding that is to say 
parsing a blob a string that might contains null ie.
in py_security.c:

static PyObject *py_dom_sid_ndr_unpack(PyObject *py_obj, PyObject *args)
{
   struct dom_sid *object = (struct dom_sid *)py_talloc_get_ptr(py_obj);
   DATA_BLOB blob;
   enum ndr_err_code err;
   if (!PyArg_ParseTuple(args, "s#:__ndr_unpack__", &blob.data, 
&blob.length))
     return NULL;
...

It works great in 32 bits because blob.length has a size of 4 bytes and 
an int also ! but in 64 bits it don't as blob.length is a size_t value 
with in this case 8 bytes length. So in some case the 4 upper bytes can 
contains non null bytes which leads the C to error because it thinks 
that the size of the blob is HUGE.

I fixed my binding by forcing the blob.length to 0 before calling 
PyArg_ParseTuple. This obviously works only for blobs smaller than 2G 
(because it's not clear if the int is signed or not), which might be 
enough for a few days !

I tried as I said previously on a ext2 FS mounted in the source4/st dir 
without user_xattr (-o nouser_xattr) the test clearly indicate that the 
test using user xattr is skipped.

Andrew B advised me to remove xattr.h but even without them configure 
manage to detect the library and use it. Removing is not an option as it 
breaks the system ... (ls/cp/rm are linked with libattr1).
I didn't find a FS not supporting xattr, ufs is only in readonly, bfs do 
not support directory, all the rest has xattr in it and only user_xattr 
can be desactivated.


Hopefully with all the bug that you reported we scanned the case of 
failure when xattr are not present.

As usual the whole patch list is in my repo at 
git://repo.or.cr/Samba/ekacnet.git in the branch merge-acl-prov

On 17/01/2010 01:43, Matthieu Patou wrote:
> Hello all,
>
>>> [596/608 in 1819s, 1 errors] samba4.ldap_schema.python (dc)
>>> [597/608 in 2034s, 1 errors] samba4.ldap.possibleInferiors.python (dc)
>>> [598/608 in 2036s, 1 errors] samba4.ldap.secdesc.python (dc)
>>> [599/608 in 2270s, 1 errors] samba4.ldap.acl.python (dc)
>>> [600/608 in 2300s, 1 errors] samba4.xattr.python
>>> UNEXPECTED(error):
>>> samba4.xattr.python.samba.tests.xattr.XattrTests.test_set_and_get_native
>>> REASON: Traceback (most recent call last):
>>> File "bin/python/samba/tests/xattr.py", line 60, in
>>> test_set_and_get_native
>>> samba.xattr_native.wrap_setxattr(tempf,"user.unittests",reftxt)
>>> TypeError: Operation not supported
>>> UNEXPECTED(error):
>>> samba4.xattr.python.samba.tests.xattr.XattrTests.test_set_xattr_native
>>> REASON: Traceback (most recent call last):
>>> File "bin/python/samba/tests/xattr.py", line 44, in
>>> test_set_xattr_native
>>>
>>> samba.xattr_native.wrap_setxattr(tempf,"user.unittests",ndr_pack(ntacl))
>>> TypeError: Operation not supported
>>> command: /usr/bin/python2.5 ./selftest/../scripting/bin/subunitrun
>>> samba.tests.xattr
>>> expanded command: /usr/bin/python2.5
>>> ./selftest/../scripting/bin/subunitrun samba.tests.xattr
>>> ERROR: Testsuite[samba4.xattr.python]
>>> REASON: Subunit/Filer Reason
>>> errors[2]
>>
>> I get this same error on Fedora 12 i686
> In a way I'm surprised, in another it shows that the tests was not
> complete enough.
> So surprised because this test use user xattr to test that the python
> binding is able to manipulate xattr, and unless that you have a
> filesystem with -o nouser_xattr as an option then it should work (at
> least it's like that on my ubuntu and it seems to be also the same on my
> fedora 12 i386 with a ext4 fs).
> In any case it shows that the tests should check if the FS support xattr
> and if not skip it.
> I changed the code so that the python binding returns a different
> exception if we face a ENOTSUP error while calling wrap_(g|s)etxattr.
>
> No it seems ok on my ubuntu with a filesystem mounted nouser_xattr
> (while setfattr -n "user.foo" -v "bar" foobar fails).
>
>
>>
>> Andrew Bartlett
>
> Matthieu.