#4060 Inherit parent folder permissions for folders owned by an AD group
Closed: wontfix a year ago by pbrezina. Opened 2 years ago by yoshikim.

Folders that are owned by AD_user:AD_group_gid don't inherit parent folder permissions with chmod g+s.

mkdir /folder
chown AD_user:<AD_group_gid> /folder
chmod -R o-wrx /folder
chmod -R u+wrx /folder
chmod -R g+wrxs /folder

Expected result is for users in AD_group to be able to modify sub folders and files but
Subfolders and files won't inherit permissions.
Users in the same AD_group aren't able to modify files in a subfolder another user created.

This process works with local accounts. I'd like to fully move away from local accounts but this is holding back.

What information can I provide to assist with this

Is the group the user is assigned to correct? If yes, then that's all sssd has to do with permissions. Inheritance of permissions is not something sssd handles.

Thought I'd check here since the issue only happens when bound to AD and granting access via AD Groups. Would there be any configurations I can try in the sssd.conf file? Curious if anyone else ran into this issue and has a solution. Here's the current conf.

domains = my.domain.com
config_file_version = 2
services = nss, pam

ad_domain = my.domain.com
krb5_realm = MY.DOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
access_provider = ad
ignore_group_members = True


As I said, sssd does not handle directory permissions at all, this is all handled on the FS level.

The only thing that sssd does is to assign the user to a primary group and a list of supplementary groups. If you run "id user" then is the group output what you would expect?

Metadata Update from @thalman:
- Issue tagged with: Canditate to close

a year ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

a year ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/5028

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.