Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't add second item to a share's access control list #2092

Open
gallogabor opened this issue May 11, 2022 · 2 comments
Open

Can't add second item to a share's access control list #2092

gallogabor opened this issue May 11, 2022 · 2 comments
Assignees
Labels
Reason: Cannot reproduce Indicates that an issue couldn't been reproduced Status: Question Indicates that an issue or pull request needs more information Type: Bug Indicates an unexpected problem or unintended behavior

Comments

@gallogabor
Copy link

Describe the bug
If I try to add a second (third, etc.) user or group to a share's access control list with read/write rights, then nothing happens on file system level.
I add the extra item to the list in the webadmin GUI, save changes (which done successfully), but affected users can't access the share.
If I check the file system level ACL with getfacl command, then the newly added user/group not shown in the resulting list for the folder.

If I add the second item to the ACL as read only, then it is added to the file system level ACL and affected users can read the share's content. But if I change the ACL from read only to read/write, nothing happens, file system level ACL remains read only.

So, it seems that only one read/write ACL can be added to a share, any other ACL items must be read only to be saved corrwectly on file system by Zentyal webadmin.

I found a workaround: if I add the extra ACL items as read only, save/apply changes on webadmin GUI, then change to read/write, the save/apply again in webadmin GUI, and correct it on file system level with setfacl command (to change the r-x to rwx for the newly added items), then the webadmin and file system ACL lists will be consistent and affected users can write to the share, but this is not the expected behaviour I think.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'File Sharing'
  2. Click on 'Access Control' column's icon for any defined share
  3. Add a new ACL with 'Add new...' button, select any user or group, then select 'Read and write' in the 'Permissions' drop-down
  4. Add with '+ Add' button
  5. Save setting with the orange button in the top right corner
  6. After successful save operation on the web GUI check file system level permissions with getfacl on the selected share's folder
  7. The newly added user/group will not be there in the getfacl output

Expected behavior
All ACL entries show up in file system level ACL exactly as set up in the webadmin GUI after save/apply on webadmin GUI.

Zentyal OS (please complete the following information):

  • Version: 7.0.4, original 7.0 install, not an upgrade from 6.x
  • Version of the module which has the bug: I don't know which module sets file system permissions
  • Modules installed Domain Controller, NTP, DNS, Network, Firewall, Logs

Other OS (please complete the following information):

  • OS: Ubuntu 20.04.4 LTS
  • Fully updates as of 2022.05.10
@gallogabor gallogabor added the Type: Bug Indicates an unexpected problem or unintended behavior label May 11, 2022
@djoven89 djoven89 added Status: Question Indicates that an issue or pull request needs more information Reason: Cannot reproduce Indicates that an issue couldn't been reproduced labels May 20, 2022
@djoven89
Copy link
Contributor

Hi @gallogabor ,

We tried to reproduce this issue but we couldn't. We got the expected behavior.

Can you please check the log file '/var/log/zentyal/zentyal.log'? When an ACL is changed in the GUI and save changes, the script SyncDaemon.pm is executed to perform the necessary actions. Below you have an example of the server we used to test this issue:

2022/05/20 11:47:27 INFO> SambaShares.pm:186 EBox::Samba::Model::SambaShares::tagShareRightsReset - Tagging share 'devops' as requiring a permission reset

2022/05/20 11:47:41 INFO> SyncDaemon.pm:340 EBox::Samba::SyncDaemon::run - Samba sync daemon started

2022/05/20 11:47:42 INFO> SyncDaemon.pm:268 EBox::Samba::SyncDaemon::setACLs - Starting to apply recursive ACLs to share 'devops'...

2022/05/20 11:47:42 INFO> SyncDaemon.pm:326 EBox::Samba::SyncDaemon::setACLs - Recursive set of ACLs to share 'devops' finished.

@djoven89 djoven89 self-assigned this May 20, 2022
@gallogabor
Copy link
Author

gallogabor commented Jul 6, 2022

Hi @djoven89,

I'm sorry for the late update, but I didn't have spare time for this customer's Zentyal system in the past month.

I'm done some testing after reading your comment/question and doing some examination of the SyncDaemon.pm file.

I did found the following (and I checked it on an another 7.0.4 install at another cusmers, and that is working identically wrong as the system I'm testing now):

The procedure you mentioned is the same on my systems (checked the log file), but happens in the wrong order I think.

When I add/edit an ACL of a share, after I save the added/edited ACL, the webgui immediately tagging my share as "ACL sync needed" (shown in /var/log/zentyal/zentyal.log). In practice, this means a file (named after the share) was created as /var/lib/zentyal/conf/samba/sync_shares/SHARENAME. The background-running SyncDaemon checks this folder repeatedly, and syncs ACLs for the shares it found there (if I understand the program code right). But the config "database" at this point only contains the unmodified ACLs for that share, because I didn't pressed the orange apply changes button at top right. So SyncDaemon modifies ACLs on filesystem to the state as before my edit...
When I press the orange apply button top right, config "database" receives the changed ACLs and stores them, but SyncDaemon does nothing after this, because the webgui do not create the flag file again (in /var/lib/zentyal/conf/samba/sync_shares). So, the filesystem ACLs represent the previous config version in effect before my last edit.
For example if I change a read-only to read-write, the read-only gets propagated to the FS (not the read-write I selected last), then I change back to read-only (from previous read-write), this time the previous read-write gets propagated to FS. FS ACL always one step behind webgui config version...
I succeeded only one time pressing the orange apply button quick enoung to update the config "database" sooner than the scheduled run of SyncDaemon. All other times the webgui is not quick enough to save the changes before next SyncDaemon run. And, of course, if I make more than one change to one or more share's ACL's, then none of the last modifications gets applyed to the file system ACLs automatically.
For a test to confirm my theory, after I pressed the orange apply button top right, and when webgui stated all modifications were saved, I ran touch /var/lib/zentyal/config/samba/sync_share/SHARENAME over SSH, then, after a few seconds, SyncDaemon picked up that flag file and applied the current (last, webgui shown) ACLs to the FS.

So I think the problem is that on my 7.0.x systems, SyncDaemon receives a sync command for the share before I save the ACL changes to config "database" with the orange apply button top right...

I don't know I did something wrong at install time, or do when using the system, but this happens always on every share ACL change on at least two Zentyal 7.0.x system at different customers.
If your need some more testing, log file snippets, a timeline, or anything else, please tell me and I collect it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Reason: Cannot reproduce Indicates that an issue couldn't been reproduced Status: Question Indicates that an issue or pull request needs more information Type: Bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants