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.h....
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!
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.h....
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?
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.h....
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.
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.h....
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
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.h... .
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.o...
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 <fidencio@redhat.com mailto:fidencio@redhat.com> wrote:
On Fri, Feb 8, 2019 at 8:30 AM Alexander Bokovoy <abokovoy@redhat.com <mailto: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 <mailto:sssd-devel@lists.fedorahosted.org> To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org <mailto: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
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.o...
Levin,
On Tue, Feb 12, 2019 at 8:21 AM Levin Stanislav slev@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.
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.
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@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.h....
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.o...
-- 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-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.o...
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.o...
18.02.2019 11:11, Fabiano Fidêncio пишет:
Levin,
On Tue, Feb 12, 2019 at 8:21 AM Levin Stanislav slev@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
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.
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@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.h....
> 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.o...
-- 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-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.o...
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.o...
On Mon, Feb 18, 2019 at 10:13 AM Levin Stanislav slev@altlinux.org wrote:
18.02.2019 11:11, Fabiano Fidêncio пишет:
Levin,
On Tue, Feb 12, 2019 at 8:21 AM Levin Stanislav slev@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@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.h.... > >> 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.o...
-- 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-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.o...
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.o...
sssd-devel@lists.fedorahosted.org
-
Alexander Bokovoy -
Fabiano Fidêncio -
Fabiano Fidêncio -
Jakub Hrozek -
Levin Stanislav -
Oliver Gutierrez