[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-337-g73e9693

[boyang]

Volker Lendecke wrote:
> On Mon, Aug 03, 2009 at 07:52:55PM +0800, boyang wrote:
>   
>> Do you mean a test include in torture/torture.c or a separately
>> independent piece of code? I'll do it.
>>     
>
> A test in torture/torture.c or in source4/torture/basic/, as
> you like it.
>   
Looks like we all are wrong, partly. I will describe in the following
aspects:
1. test case
2. test results
3. my analysis

1. Test Case:
    one connection to the share, and another connection to the pipe with
command ./bin/shareperm //host/share -P'pipeuser%pipepass' -U'user%pass'.
    Preparation:
    set up a share on window2003, which user has full access to. set up
a share on linux box which user has full access, my configuration on
linux is in attachment. on linux, uses ./bin/sharesec sharename -R
"'user's SID:ALLOWED/0/0x1f01ff" to set the acls. My linux machine is a
domain member of the domain. And it must be, I think. Otherwise
lookupname in the code will fail.
    eg, I have a user NODNSUPDATE\nodns1, set  NODNSUPDATE\nodns1  has 
full  access  on  linux share and windows share. I've used
NODNSUPDATE\Administrator as the pipe user.  And to avoid surprise,
nodns1 is the only user has access to the two shares.
   Test summary:
   a) open and write to the file ---> close the file but keep connection
to the share open ---> set the share to readonly for user ---> try to
reopen the file and write to it ----> reset share info to initial stat.
[SHARE_PERMCHG_REOPEN]
   b) open and write file ---> keep the file open and set share info
---> write to it again, both linux and windows succeeds.
[SHARE_PERMCHG_NOREOPEN]
   c)open and wirte file ---> delete the share ---> reopen the file with
existing tree connection ----> write again. [SHARE_DEL_REOPEN]
   d)open and write file ---> delete the share ---> keep the file open
and write to it again. [SHARE_DEL_NOREOPEN].

2. Test result:
    windows:
            [SHARE_PERMCHG_REOPEN]: detected change, second write failed.
            [SHARE_PERMCHG_ONREOPEN]: don't detect change, second write
succeeded.
            [SHARE_DEL_REOPEN/NOREOPEN]: detected the change, both of
the second write failed.
    linux:
            [SHARE_PERMCHG_REOPEN]: didn't detect change, second write
succeeded.
            [SHARE_PERMCHG_ONREOPEN]: don't detect change, second write
succeeded.
            [SHARE_DEL_REOPEN/NOREOPEN]: didn't detect the change, both
of the second write succeeded.  

3. my analysis and some bugs:
    bug: usershare won't work with NetShareSetInfo, the
usershare_path/sharename file is never get updated. Acls are only
updated in share_info.tdb. So, we cannot use usershare for test.
   Analysis:
   windows:
       For already opened files, share permission change won't affect
them. For newly opened files, share permission change takes effect, even
they are open on the existing connection to the share.
       For share being deleted, disconnect all connections connected to
the share/tree.
   Linux:
      For already open files or newly opened files on existing
connection to share, permission change won't take effect...
      For share being deleted, if connection to the share/tree still
exists, samba just receive new open file request and let the client do
write...

My solution here is that:
      The reload of usershare is necessary when changes of usershare
happen. For every open file operation, we must check it against file
permission as well as share permission. And when check it against share
permission, we *must not* use cache(the vuid_cache), we must perform a
access check from startup, ignoring any existing cache. I am wrong to
touch the already opened fsps.
      For shares deleted, we should disconnect all connections connected
to this share/tree...
     
      Post my test config here. The add_share.sh and change_share.sh
need modificaiton, which are quite crap... The test code is mostly
copied from source3/torture/torture.c. I cannot add it to torture.c,
which results in linking crap. :-( Therefore, you have to patch your
master branch with the patch in attachment, and then use make
sharepermchg to get the binary of the test code. Sorry!

 Thanks!
> Volker
>   


-- 
Bo Yang, Software Engineer, Suse Labs
GPG-key-ID   538C4C1A
Samba Team   boyang at samba.org    http://www.samba.org/
SUSE Linux   boyang at suse.de      http://www.novell.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testshareperm.tar.bz2
Type: application/x-bzip
Size: 11736 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090805/541a064b/attachment.bin>