On Tue, Nov 29, 2016 at 12:55:58PM +0100, Lukas Slebodnik wrote: > On (29/11/16 12:13), Fabiano Fidêncio wrote: > >On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio <[email protected]> > >wrote: > >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik <[email protected]> > >> wrote: > >>> On (28/11/16 11:27), Jakub Hrozek wrote: > >>>>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > >>>>> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > >>>>> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > >>>>> > > The design page is done [0] and it's based on this discussion [1] we > >>>>> > > had on this very same mailing list. A pull-request with the > >>>>> > > implementation is already opened [2]. > >>>>> > > > >>>>> > > [0]: > >>>>> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >>>>> > > [1]: > >>>>> > > https://lists.fedorahosted.org/archives/list/[email protected]/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >>>>> > > [2]: https://github.com/SSSD/sssd/pull/84 > >>>>> > > > >>>>> > > The full text of c&p here: > >>>>> > > >>>>> > In general looks good to me, but note that I was involved a bit with > >>>>> > Fabiano in the discussion, so my view might be tainted. > >>>>> > >>>>> I finally got to it. The design page looks good and I'll start > >>>>> reviewing the > >>>>> patches. > >>>>> > >>>>> The only think I wonder about is whether we want to pass parameters " > >>>>> --uid > >>>>> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > >>>>> reading them. > >>>>> > >>>>> Also what do we use the private sockets for? It is used only for root? > >>>> > >>>>Yes, that's where we route PAM requests started by UID 0 to. > >>>> > >>> For example. The nss responder need't run as root. It does not require > >>> any extra privileges. And the privileges are dropped as soon as possible. > >>> The only issue might be with switching from root to non-root. > >>> A responder need to change owner of log files. > >>> But it could be solved with ExecStartPre in service file > >>> > >>> e.g. > >>> ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log > >>> ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files > >>> User=sssd > >>> Group=sssd > >>> PermissionsStartOnly=true > >>> > >>> @see the explanation of PermissionsStartOnly in man 5 systemd.service > >> > >> I like the suggestion. But I also would like to ask which are the > >> responders that have to executed as root? > > > >This question still stands ... > > > >We have the following responders: autofs, ifp, nss, pac, pam, ssh and sudo. > >All of those can run as sssd user? > > > sh$ cd src/responder/ > > sh$ git grep server_setup . > autofs/autofssrv.c: ret = server_setup("sssd[autofs]", 0, uid, gid, > ifp/ifpsrv.c: ret = server_setup("sssd[ifp]", 0, 0, 0, > nss/nsssrv.c: ret = server_setup("sssd[nss]", 0, uid, gid, > CONFDB_NSS_CONF_ENTRY, > pac/pacsrv.c: ret = server_setup("sssd[pac]", 0, uid, gid, > pam/pamsrv.c: * in server_setup() */ > pam/pamsrv.c: ret = server_setup("sssd[pam]", 0, uid, gid, > CONFDB_PAM_CONF_ENTRY, &main_ctx); > secrets/secsrv.c: ret = server_setup("sssd[secrets]", 0, uid, gid, > CONFDB_SEC_CONF_ENTRY, > ssh/sshsrv.c: ret = server_setup("sssd[ssh]", 0, uid, gid, > sudo/sudosrv.c: ret = server_setup("sssd[sudo]", 0, uid, gid, > CONFDB_SUDO_CONF_ENTRY, > > As you can see only ifp responder uses hardcoded values (uid=0, gid=0) > instead of values passed from command line.
This was IIRC because of the OpenLMI config-changing interface, so I think this requirement can be removed. > > Most of responders are quite dummy and does not require any extra privileges. > they either can found data in cache or request data from backend. > Backends are more complicated because the most of logic is there > but they are not related to your work with socket activated services atm. > > LS > _______________________________________________ > sssd-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
