Currently dbus service org.freedesktop.FleetCommanderClient is executed when called from SSSD when it finished the JSON file deployment. It is executed as root so it can create the paths it needs under several places for each supported configuration module.

The only thing I see here is the domain directory it is not needed to  be owned by user/user group, only the user directories need to be owned by the user (and it is not really needed because org.freedesktop.FleetCommanderClient is run as root, but it is better to leave that way so we can access that information from user session if needed).


On Mon, Feb 11, 2019 at 2:40 PM Fabiano Fidêncio <fidencio@redhat.com> wrote:
On Fri, Feb 8, 2019 at 8:30 AM Alexander Bokovoy <abokovoy@redhat.com> wrote:
>
> On to, 07 helmi 2019, Jakub Hrozek wrote:
> >On Thu, Feb 07, 2019 at 05:51:06PM +0300, Levin Stanislav wrote:
> >> Hello,
> >>
> >> I want to ask you about design of fleet commander integration, which I
> >> found on
> >> https://docs.pagure.org/SSSD.sssd/design_pages/fleet_commander_integration.html.
> >>
> >> > The JSON files will be stored in a new directory owned by the
> >> > |sssd-ipa| subpackage. The top-level directory could be at
> >> > |/var/lib/sss/deskprofile/| with per-user subdirectories. So each
> >> > per-user JSON file would be stored at
> >> > |/var/lib/sss/deskprofile/<domain>/<username>/<profilename>.json|. The
> >> > |<username>| directories need to be owned by the user being logged in.
> >> > /var/lib/sss/deskprofile/<domain>/<username>/<profilename>.json
> >> >             ------------ -------- ---------- ------------------
> >> >                  |          |          |            |
> >> >                  v          |          |            |
> >> > Created by sssd package as  |          |            |
> >> > root:root (or sssd:sssd)    |          |            |
> >> > and has permissions 0751    |          |            |
> >> >                             |          |            |
> >> >                             v          |            |
> >> >             Owned by user:user_group   |            |
> >> >             and has permissions 0751   |            |
> >> >                                        |            |
> >> >                                        |            |
> >> >                                        v            |
> >> >                     Owned by user:user_group        |
> >> >                     and has permissions 0700        |
> >> >                                                     |
> >> >                                                     v
> >> >                                     Owned by user:user_group
> >> >                                     and has permissions 0400
> >>
> >> As I see FleetCommander is executed with root privileges (without CAPs
> >> dropping) and is allowed to read user profiles.
> >>
> >> Why is "user" owner of the directory "<username>"? and why should we
> >> grant "user" with any permissions for this path?
> >>
> >> Why is it not just 0700 for dirs, 0400 for profiles, owner
> >> root/sssd_user for all subpaths?
> >>
> >> Could you please explain?
> >>
> >> Thank you in advance!
> >>
> >
> >Fabiano, do you remember?
> I think the original idea was that org.freedesktop.FleetCommanderClient
> runs the settings merge process under actual user. That might have been
> refactored later.

That's exactly what Alexander mentioned. And, no, AFAIR, it was not
refactored later on.

>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org


--
Oliver Gutierrez
Associate Software Engineer - Desktop Management tools
Red Hat