Thank you All for the kind support and explanation!

My problem is well described here:

https://pagure.io/SSSD/sssd/issue/3638,

which come due to https://pagure.io/SSSD/sssd/issue/3621.


As I understand #3621 changes are unnecessary right now because they
have relied on an assumption on future use.

Thus, mostly #3621 is an optional feature, right?

Any thoughts?

Is there a chance to see a related fix in upstream?


Reading thats issues I saw different opposite points of view about
support for non-privileged user.

Please, feel free to tell me if you are not interested in.

Thank you.



11.02.2019 18:16, Oliver Gutierrez пишет:
> 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 <fiden...@redhat.com
> <mailto:fiden...@redhat.com>> wrote:
>
>     On Fri, Feb 8, 2019 at 8:30 AM Alexander Bokovoy
>     <aboko...@redhat.com <mailto:aboko...@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
>     <mailto:sssd-devel@lists.fedorahosted.org>
>     To unsubscribe send an email to
>     sssd-devel-le...@lists.fedorahosted.org
>     <mailto:sssd-devel-le...@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
>
>
> _______________________________________________
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@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

Reply via email to