Bug 6261 - Excel save operation incorrectly adds user to the file ACL
Excel save operation incorrectly adds user to the file ACL
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.34
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-14 17:32 UTC by Bill Marshall
Modified: 2009-10-28 13:15 UTC (History)
4 users (show)

See Also:


Attachments
level 10 log from 1st client accessing the excel file (594.55 KB, application/x-gzip)
2009-04-15 11:25 UTC, Bill Marshall
no flags Details
level 10 logs from 2nd client accessing the excel file (789.06 KB, application/x-gzip)
2009-04-15 11:25 UTC, Bill Marshall
no flags Details
smb.conf, including share pm400fac (2.31 KB, text/plain)
2009-05-04 15:44 UTC, Bill Marshall
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Marshall 2009-04-14 17:32:41 UTC
jra -- as much as I hate to say it. This is very close to bug 4308.

I have level 10 logs from 2 clients that I will upload.

Running samba-3.0.33-0.el4.13 (RHEL 4) -- the code that was supplied as a fix for #4308 -- users reported a problem today where a user was not able to write to a file that he previously has access to.

All the users on the ACL below are in the group facwrite. As the file is updated, the users have "migrated" from the file owner onto the ACL and sometimes the ACL ends up as: user::r-x. The user/owner then looses access to the file.

Here's some snapshots as 2 users opened and edited a file. (But not starting at the beginning. The problem has already happened and vc882l was "locked out"

Here is the ACL on the directory:
# cd Integration\ Testing/
[root@rchs85gd Integration Testing]# getfacl .
# file: .
# owner: vc7euu
# group: domain\040users
user::rwx
group::--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::--x
default:user::rwx
default:group::--x
default:group:domain\040admins:rwx
default:group:facwrite:rwx
default:mask::rwx
default:other::--x


# getfacl  New*
# file: NewBusinessTestStatus.xls
# owner: vc8n7c
# group: domain\040users
user::rwx
user:vc7yvj:rwx
user:vc882l:r-x
group::--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::--x

I removed an ACL entry using the Windows GUI to allow everyone to write again.

# getfacl  New*
# file: NewBusinessTestStatus.xls
# owner: vc8n7c
# group: domain\040users
user::rwx
user:vc7yvj:rwx
group::--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::--x

Next, vc882l opens and saves the file. For some reason, user::r-x is set.

# getfacl  New*
# file: NewBusinessTestStatus.xls
# owner: vc882l
# group: domain\040users
user::r-x
user:vc7yvj:rwx
user:vc8n7c:rwx
group::--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::--x

Check time stamp
# ls -l   New*
-r-xrwx--x+ 1 vc882l domain users 47104 Apr 14 08:43 NewBusinessTestStatus.xls


8:45:15 AM: William Marshall: scott can you open and save
8:45:37 AM: scott: Cleared two fields...and saved ok.
8:45:40 AM: scott: closed
8:45:51 AM: William Marshall: vc882l is now broken

# getfacl  New*
# file: NewBusinessTestStatus.xls
# owner: vc8n7c
# group: domain\040users
user::rwx
user:vc7yvj:rwx
user:vc882l:r-x
group::--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::--x
Comment 1 Bill Marshall 2009-04-15 11:25:06 UTC
Created attachment 4065 [details]
level 10 log from 1st client accessing the excel file
Comment 2 Bill Marshall 2009-04-15 11:25:45 UTC
Created attachment 4066 [details]
level 10 logs from 2nd client accessing the excel file
Comment 3 Simo Sorce 2009-05-02 09:42:56 UTC
(In reply to comment #0)
> jra -- as much as I hate to say it. This is very close to bug 4308.
> 
> I have level 10 logs from 2 clients that I will upload.

Can you provide also the smb.conf file (global and share specific bits are enough)
Comment 4 Simo Sorce 2009-05-02 09:56:13 UTC
(In reply to comment #0)

> Next, vc882l opens and saves the file. For some reason, user::r-x is set.

Does one of the 2 logs you posted capture this event ?

I really need to see when the ACL is set.
Comment 5 Bill Marshall 2009-05-04 15:38:03 UTC
Simo - I hope the problem is in the trace. I didn't try and read the traces. However, only 2 clients were working on the file. And the trace ran during the whole conversation below, while the ACL changed a few times.
Comment 6 Bill Marshall 2009-05-04 15:44:55 UTC
Created attachment 4112 [details]
smb.conf, including share pm400fac
Comment 7 Bill Marshall 2009-05-19 11:59:07 UTC
User just reported, the ACL "broke" on a file that he is the only person using. Previously we thought that the problem was related to multiple users:

Notice - user::r

# file: Scheduled\040Jobs\040PM5.xls
# owner: vc8n7c
# group: domain\040users
user::r--
user:root:rw-
group::---
group:root:--x
group:domain\040admins:rwx
group:facwrite:rwx
mask::rwx
other::---

Last Friday we added the parm "map acl inherit=yes" to the share. On bug 4308 this would make the ACL problem go away. It doesn't seem to be a work-around here.
Comment 8 Bill Marshall 2009-05-19 12:09:55 UTC
Simo - last time you and jra mentioned that it would be good to have some debug statements in the ACL code. Did anything get added? And and what log level?
Comment 9 Bill Marshall 2009-05-19 15:33:46 UTC
My settings are (were):
    map acl inherit = No
    map archive = No
    map hidden = No
    map system = No
    map readonly = yes

So this last line might be a config problem. Changing to no and testing.
Comment 10 Simo Sorce 2009-10-28 09:01:24 UTC
(In reply to comment #9)
> My settings are (were):
>     map acl inherit = No
>     map archive = No
>     map hidden = No
>     map system = No
>     map readonly = yes
> 
> So this last line might be a config problem. Changing to no and testing.



Bill I can't repro with a sane config.
maybe your problem is cause by "map readonly = yes"
I strongly suggest that you set it to no and use store dos attributes = yes instead to store dos flags into an exetended attribute instead.

I'll try some more and try with map readonly =yes, but if that's the culprit then I'll close this bug as a configuration error, as mapping dos attributes on unix permissions is know to make acls hairy.

Comment 11 Simo Sorce 2009-10-28 09:02:56 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > My settings are (were):
> >     map acl inherit = No
> >     map archive = No
> >     map hidden = No
> >     map system = No
> >     map readonly = yes
> > 
> > So this last line might be a config problem. Changing to no and testing.
> 
> 
> 
> Bill I can't repro with a sane config.
> maybe your problem is cause by "map readonly = yes"
> I strongly suggest that you set it to no and use store dos attributes = yes
> instead to store dos flags into an exetended attribute instead.
> 
> I'll try some more and try with map readonly =yes, but if that's the culprit
> then I'll close this bug as a configuration error, as mapping dos attributes on
> unix permissions is know to make acls hairy.
> 

Bah on a second read "map readonly" should do nothing, as the parm name is "map read only" ...
Comment 12 Bill Marshall 2009-10-28 11:42:53 UTC
A few bugs ago on a different excel bug, jra told us to try:
map acl inherit=yes

If we set "map acl inherit=yes" on this share, the problem doesn't happen.

On this system, we currently have: 
testparm -l -v -s | grep -i read
 map readonly = no

There's no space in readonly in the testparm output, so which was is it?

Also, I'll agree this appears to be different that what I reported in May.
Comment 13 Simo Sorce 2009-10-28 13:15:07 UTC
(In reply to comment #12)
> A few bugs ago on a different excel bug, jra told us to try:
> map acl inherit=yes
> 
> If we set "map acl inherit=yes" on this share, the problem doesn't happen.

Ok I tried with both map acl inherit yes and no and still can't repro.
Can you tell me what are the client OSs and what Excel version ?
Or have you seen this on multiple client/office versions combination ?

> On this system, we currently have: 
> testparm -l -v -s | grep -i read
>  map readonly = no
> 
> There's no space in readonly in the testparm output, so which was is it?

Bah, go trust smb.conf man page .. I just looked in the code and you are right sir, it's "map readonly".

> Also, I'll agree this appears to be different that what I reported in May.


What I find also strange is that when I manipulate the files, I don't see new ACLs for the second user changing the file.
I just see as owner the initial user that created the file and that seem to never change here.

Can you give me an overview of the membership relation between the groups in the ACLs and the users in the ACLs ?