On Mon, Feb 18, 2019 at 10:13 AM Levin Stanislav <slev(a)altlinux.org> wrote:
18.02.2019 11:11, Fabiano Fidêncio пишет:
> Levin,
>
> On Tue, Feb 12, 2019 at 8:21 AM Levin Stanislav <slev(a)altlinux.org> wrote:
>> 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?
> #3621 is something that has been fixed already and the code does not
> require DAC_OVERRIDE and the fix is upstream for a long time.
Fabiano, talking about #3621 I mean:
FC: SSSD: User has to own his profile and directory of profile
SSSD: FC: No concerns, I will use my root DAC_OVERRIDE
Systemd: SSSD: DAC_OVERRIDE is too much for you
SSSD: Systemd: No concerns, I will use my root CAP_SETGID and CAP_SETUID
(#3621)
FC: SSSD: actually, we don't need user permissions for his profile so far
I'm not exactly sure on what you mean here.
We changed permissions in order to avoid hitting issues wrt DAC_OVERRIDE.
I'm not sure, though, whether something else was change since I lef
SSSD project.
>
>>
>> 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.
>
> About #3638, having SSSD fully running for unprivileged users is
> something that, IMO, is not going to happen anytime soon (but SSSD
> developers may jump in and correct me). Considering it's not going to
> happen, I'd assume that #3638 wouldn't happen any faster. :-)
>
> Of course, if there are patches to make everything work with
> unprivileged users and SSSD team has the time to review and merge
> those. But, please, be patient as it may take some long time till your
> patches get reviewed due to the high workload of SSSD team.
From my side, I have to use non-privileged user and have to apply FC anyway.
I would be happy to contribute to SSSD. Just point me in the right
direction / idea.
Jakub is the right person to point you at the right direction for that
(as I'm not part of SSSD project anymore).
Please, just, please, do sync with Oliver Gutierrez to ensure that the
changes won't break Fleet Commander integration.
Thank you for your time.
>
>> 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 <fidencio(a)redhat.com>
wrote:
>>> On Fri, Feb 8, 2019 at 8:30 AM Alexander Bokovoy <abokovoy(a)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_integratio....
>>>>>>
>>>>>>> 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(a)lists.fedorahosted.org
>>> To unsubscribe send an email to sssd-devel-leave(a)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.fedorahoste...
>>
>>
>> --
>> Oliver Gutierrez
>> Associate Software Engineer - Desktop Management tools
>> Red Hat
>>
>>
>> _______________________________________________
>> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-devel-leave(a)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.fedorahoste...
>>
>>
>> _______________________________________________
>> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-devel-leave(a)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.fedorahoste...
>
>
--
Fabiano Fidêncio