On Mon, 2018-01-22 at 15:10 +0100, Fabiano Fidêncio wrote: > People, > > Let's start with the context of this email: > https://bugzilla.redhat.com/show_bug.cgi?id=1536854 > So, seems that even without knowing that, I've relied on CAP_DAC_OVERRIDE > in order to have the Fleet Commander integration working as expected and in > the implementation details of this feature. > > The desktop profiles are stored in a dir like: > /var/lib/sss/deskprofile/$domain/$user/$profile. > > Currently, the way I've been creating those are: > $domain = 755 (root:root) > $user = 600 ($user:$user_group) > $profile = 600 ($user:$user_group) > > Now, as mentioned in the bugzilla linked in this email, the current code > fails with an EACCES. > > With all this background, I'd like to discuss what's the best approach to > take. I've opened a PR (https://github.com/SSSD/sssd/pull/498) which makes > everything work again, but does the following changes: > > $domain = 755 (root:root) -- NO changes here > $user = 770 ($user:root) --> changed from 600 ($user:$user_group) > $profile = 660 ($user:root) --> changed from 600 ($user:$user_group) > > This is one way to solve the issue suggested at > https://bugzilla.redhat.com/show_bug.cgi?id=1536854#c5. > > Another suggestion, also mentioned in the bugzilla, would be to only > fchown()/fchmod() the files/dirs *after* all the operations we do are over. > > Is there any other suggestion? Whatever comes out of this discussion will > be used to update the feature's design page accordingly.
Change euid to that of the user during operations, leave the permissions strict ? Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
