[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ and I will check rest of ldap + AD related tests tomorrow. """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-263641880 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ Few multi domain tests failed: The first one was related to enumeration. Other failures probably as well. ``` [sssd domains = LOCAL,LDAP services = nss, pam [nss] filter_groups = root filter_users = root [pam] [domain/LOCAL] enumerate = TRUE id_provider = local max_id = 2010 min_id = 2000 use_fully_qualified_names = TRUE [domain/LDAP] cache_credentials = FALSE enumerate = TRUE id_provider = ldap ldap_uri = ldaps://$SERVERS:636 ldap_tls_cacert = /etc/openldap/certs/cacert1.asc ldap_user_search_base = ou=people,dc=example,dc=com ldap_group_search_base = ou=groups,dc=example,dc=com max_id = 1010 min_id = 1000 use_fully_qualified_names = TRUE ``` and related test: ``` //add 2 ldap users user1 puser2 and two local users sss_useradd -u 2000 -h /home/user2000 -s /bin/bash user2000@LOCAL sss_useradd -u 2001 -h /home/user2001 -s /bin/bash user2001@LOCAL //wailt a bit for finished enumeration sleep 10 getent -s sss passwd # verify user enumeration # Users that should be returned RET=`getent -s sss passwd 2>&1` for item in puser1@LDAP puser2@LDAP user2000@LOCAL user2001@LOCAL ; do echo $RET | grep $item if [ $? -ne 0 ] ; then echo "ERROR: Expected $item user to be returned." else echo "Pass: $item user returned as expected." fi done ``` """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-263638698 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89
Title: #89: nss: rewrite nss responder so it uses cache_req
lslebodn commented:
"""
One netgroupt test failed: Decrease the cache time out and add new entry for
nisNetgroupTriple
```
echo "entry_cache_timeout = 60" >> /etc/sssd/sssd.conf
// clear cache and restart sssd
cat << EOF | ldapmodify -x -h $SERVERS -p 389 -D "cn=Directory Manager" -w
Secret123 -a
dn: cn=QAUsers,ou=Netgroup,dc=example,dc=com
objectClass: nisNetgroup
objectClass: top
cn: QAUsers
nisNetgroupTriple: (testhost1,ng9000,$HOSTNAME)
description: ALL QA users in my org
EOF
// ensure that that netgroup with ng9000 exist
getent -s sss netgroup QAUsers | grep ng9000"
// ensure that that netgroup with ng9001 does not exist
getent -s sss netgroup QAUsers | grep ng9001" && exit 1
//add netgroup with ng9001
cat << EOF | ldapmodify -x -h $SERVERS -p 389 -D "cn=Directory Manager" -w
$PASSWORD
dn: cn=QAUsers,ou=Netgroup,dc=example,dc=com
changetype: modify
add: nisNetgroupTriple
nisNetgroupTriple: (testhost2,ng9001,$HOSTNAME)
EOF
python -c "from ctypes import CDLL; from ctypes.util import find_library; libc
= CDLL(find_library('c')); x = libc.innetgr('QAUsers', None, 'ng9001',
'$HOSTNAME'); assert x == 0"
sleep 70
python -c "from ctypes import CDLL; from ctypes.util import find_library; libc
= CDLL(find_library('c')); x = libc.innetgr('QAUsers', None, 'ng9001',
'$HOSTNAME'); assert x == 1;"
```
"""
See the full comment at
https://github.com/SSSD/sssd/pull/89#issuecomment-263635715
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ Regression test for ticket https://fedorahosted.org/sssd/ticket/1229 failed. ``` > /var/log/sssd/sssd_nss.log" // clear case and restart sssd kill -STOP `pidof sssd_be`" sleep 10" getent -s sss passwd usr1 &" kill -9 `pidof sssd_be`" sleep 10" getent -s sss passwd usr1" AssertNotGrep "Identical request in progress" "/var/log/sssd/sssd_nss.log" This assetion failed. ``` I am not sure how reliable is this test but: - it passes with master - you didn't remove related debug message sssd.conf was really trivial ``` [domain/LDAP] debug_level=0xFFF0 id_provider = ldap ldap_uri = ldap://$SERVER ldap_search_base = dc=example,dc=com ldap_tls_cacert = /etc/openldap/certs/cacert.asc ``` """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-263635006 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89
Title: #89: nss: rewrite nss responder so it uses cache_req
lslebodn commented:
"""
There is a Wformat-security warning and therefore mock build failed on fedora
```
src/db/sysdb_ops.c: In function ‘sysdb_search_object_attr’:
src/db/sysdb_ops.c:4503:22: error: format not a string literal and no format
arguments [-Werror=format-security]
LDB_SCOPE_SUBTREE, attrs?attrs:def_attrs, filter);
^
```
The solution is quite simple
```
diff --git a/src/db/sysdb_ops.c b/src/db/sysdb_ops.c
index 4150c33..e8ecdeb 100644
--- a/src/db/sysdb_ops.c
+++ b/src/db/sysdb_ops.c
@@ -4500,7 +4500,7 @@ static errno_t sysdb_search_object_attr(TALLOC_CTX
*mem_ctx,
}
ret = ldb_search(domain->sysdb->ldb, tmp_ctx, &res, basedn,
- LDB_SCOPE_SUBTREE, attrs?attrs:def_attrs, filter);
+ LDB_SCOPE_SUBTREE, attrs?attrs:def_attrs, "%s", filter);
if (ret != EOK) {
ret = sysdb_error_to_errno(ret);
DEBUG(SSSDBG_OP_FAILURE, "ldb_search failed.\n");
```
"""
See the full comment at
https://github.com/SSSD/sssd/pull/89#issuecomment-263633818
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - SSSD KCM server
On Tue, Nov 22, 2016 at 09:49:52AM -0500, Stephen Gallagher wrote: > On 11/22/2016 09:38 AM, Simo Sorce wrote: > > On Tue, 2016-11-22 at 09:23 -0500, Stephen Gallagher wrote: > > >> OK, so the service is only semi-socket-activated? If we're keeping tevent > >> timers > >> around for renewals and reaping, the service won't be exiting unless all > >> tickets > >> have expired and been reaped. > >> > >> Would it be possible to look into setting non-persistent systemd timer > >> units > >> instead that would "wake up" the sssd_kcm service at appropriate times to > >> do > >> renewal and expiration? > >> > >> systemd provides the CreateTransientUnit() method on its public API that we > >> could use for this purpose. If we did it this way, then the service would > >> only > >> need to be activated whenever a ticket was actually being retrieved from > >> the > >> collection. > > > > I am trying to think if this would gain us anything. > > What would you use as a reasonable timeout to decide to exit ? > > There are other events we may want to detect in future. for example we > > may want to decide to destroy all of a user ccaches if all his sessions > > go away, this requires active probing though, but I guess it could also > > be a timer or maybe systemd has a way to notify and start a process when > > this happens too ? > > > > Well, as far as a timeout to exit, I'd probably go with a minute or two (since > you may have a short flurry of activity, such as when a user first connects > to a > VPN). I think the systemd transient units would be workable, but I also think it's not the biggest priority. For starters, we could make the service exit only when there are no credentials to be renewed or kept track about. So unless you disagree, I would file a ticket about this and proceed without any elaborate shutdown logic first. There is still a lot of work to do even without this additional functionality :) > > As far as notification of a user signing in or out, we *could* attach a helper > unit to the systemd user session default.target (and have an ExecStop command > for handling when it gets shut down too). Yes, this is something to look into. We already have https://fedorahosted.org/sssd/ticket/2551 > > >> How do containers access the KCM? Would they have to run their own copy > >> internal > >> to the container? Would we bind-mount the > >> /var/run/.heim_org.h5l.kcm-socket and > >> then work some namespacing magic in the host? > > > > Deployment specific, I can see either way as an option depending on what > > you are doing. > > > > OK, but the document doesn't describe how that might be done. We should > identify > the set of supported approaches up-front and include them in the design. > > > >> You call out in the introduction that this will help address container > >> use-cases, but then don't describe that implementation. This seems like an > >> important piece of the puzzle that should be added to the page (or made > >> more > >> clear, since if it's in there, I can't spot it). > > > > What would you want to call out exactly ? > > > > Describe a couple use-cases and the expected user experience for setting them > up > and using them. If we bind-mount the host's KCM into the container, would the > user namespacing be handled "magically" by the kernel or do we need to keep > track of which cgroup our client is and sort it into its own section of the > database? (Just for example). I added (and tested!) two, both concern containers because the single host use-case is IMO quite clear. You can find them described in detailed steps here: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM#Use-case:separatingccachesofrootusersincontainersSSSDisrunningonthehost and here: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM#Use-case:separatingccachesofcontainersfromccachesofthehost Writing up these cases was actually a nice exercise to see if the current version in my branch already covers what we wanted :) Feel free to ask if you'd like me to test and document more cases. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design discussion: Fleet Commander integration
I will add on CC to Alberto because he is the one that knows better this feature, but AFAIK the only thing to be defined in that object is that resolution order setting, and should be downloaded also with SSSD at login time so the Fleet Commander Client can read it. The global settings object seems the best option to me. On Tue, Nov 29, 2016 at 12:23 PM, Alexander Bokovoy wrote: > On ma, 28 marras 2016, Oliver Gutiérrez wrote: > >> Hi everybody, >> >> As I started to design nd develop the changes needed in Fleet >> Commander, and after a meeting with Alberto Ruiz about the things we >> need, in the FreeIPA side of the things it is all Ok. >> >> The only thing that should be added is the ability to select what is >> the priority in the desktop profile resolution. For example: The admin >> wants to setup the profile resolution should be host over group over >> user, or maybe host over user over group, or user over group over host. >> That setting should be available to set at a "global" level, so the >> Fleet Commander Client can get that setting and apply the configuration >> using that priority. That priority is apart of the numerical priority >> we already have. >> > Not sure where to put this. Rules are separate from the profiles, and > this resolution priority seem to be a third thing. Looks like it asks > for a 'desktop profile global settings' kind of object... > > What else could be defined in such an object? > > -- > / Alexander Bokovoy > > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@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
[SSSD] Re: Design discussion: Fleet Commander integration
On ma, 28 marras 2016, Oliver Gutiérrez wrote: Hi everybody, As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok. The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have. Not sure where to put this. Rules are separate from the profiles, and this resolution priority seem to be a third thing. Looks like it asks for a 'desktop profile global settings' kind of object... What else could be defined in such an object? -- / Alexander Bokovoy ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
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
> >wrote:
> >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik
> >> 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/sssd-devel@lists.fedorahosted.org/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 -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
fidencio commented:
"""
On Tue, Nov 29, 2016 at 10:05 AM, Fabiano Fidêncio
wrote:
>
>
> On Tue, Nov 29, 2016 at 9:33 AM, Pavel Březina
> wrote:
>
>> One thing I don't like about those patches is that we always recreate the
>> idle timer. Can we get around this (maybe also for the client idle
>> timeout)? What I have i mind is this:
>>
>>1. Instead of resetting the timer, remember time(NULL) of the last
>>communication, say last_request_time
>>2. Create a periodic timer that fires each responder_idle_timeout / 2
>>3. In the timer check that last_request_time + responder_idle_timeout
>>< time(NULL)
>>
>> It won't be as precise as your solution, but I don't think we need it to
>> be but it will save us lots of memory operations. What do you think?
>>
> Fine by me. Your suggestion has been used in a few other places of the our
> codebase as well.
>
After doing some tests here I do believe it may be a good approach as long
as the periodic timeout fires each 60s (that's the minimum amount of time
I'm setting up for the timeout. That looks like a good balance between
precision and number of operations, what do you think?
About the client timeout, I will do the same as it's also reset in every
communication and I also would like to use the minimum amount of time
allowed for firing for the periodic timer.
Best Regards,
--
Fabiano Fidêncio
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-263555469
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 12:13), Fabiano Fidêncio wrote:
>On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio wrote:
>> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik
>> 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/sssd-devel@lists.fedorahosted.org/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.
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 -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio wrote: > On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? > > Best Regards, > -- > Fabiano Fidêncio ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 11:48:31AM +0100, Lukas Slebodnik wrote: > On (29/11/16 11:03), Jakub Hrozek wrote: > >On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: > >> On (29/11/16 10:27), Jakub Hrozek wrote: > >> >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? > > > >This is the question, right? What do we use the private sockets for, > >like this one: > >/var/lib/sss/pipes/private/pam > >as opposed to this one: > >/var/lib/sss/pipes/pam > > > >> >> > > >> >> >Yes, that's where we route PAM requests started by UID 0 to. > >> >> > > >> >> For example. The nss responder need't run as root. > >> > > >> >I don't think this is about the identity the responder runs at, but > >> >about the identity of the client who talks to the responder socket, no? > >> > > >> I do not understant. Could you elaborate or provide an example? > >> Where you can see a problem with pure systemd solution for > >> unprivileged responders. We need to provide service files anyway. > > > >So provided I'm answering the right question :) the logic that routes > >the PAM request to /var/lib/sss/pipes/private/pam or > >/var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM > >application is running as UID 0, then the PAM module writes to > ^^^ > how is it related to running pam responder as UID 0? It is not, the question earlier was "Also what do we use the private sockets for? It is used only for root?" ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 11:03), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: >> On (29/11/16 10:27), Jakub Hrozek wrote: >> >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? > >This is the question, right? What do we use the private sockets for, >like this one: >/var/lib/sss/pipes/private/pam >as opposed to this one: >/var/lib/sss/pipes/pam > >> >> > >> >> >Yes, that's where we route PAM requests started by UID 0 to. >> >> > >> >> For example. The nss responder need't run as root. >> > >> >I don't think this is about the identity the responder runs at, but >> >about the identity of the client who talks to the responder socket, no? >> > >> I do not understant. Could you elaborate or provide an example? >> Where you can see a problem with pure systemd solution for >> unprivileged responders. We need to provide service files anyway. > >So provided I'm answering the right question :) the logic that routes >the PAM request to /var/lib/sss/pipes/private/pam or >/var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM >application is running as UID 0, then the PAM module writes to ^^^ how is it related to running pam responder as UID 0? >SSS_PAM_PRIV_SOCKET_NAME, otherwise it writes to SSS_PAM_SOCKET_NAME. Both sockets are created in function *pam_process_init* which is called after dropping privileges in *server_setup*. So I cannot see any problem for starting sssd_pam responder as unprivileged user which would be done by systemd. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 11:28 AM, Sumit Bose 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/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> [2]: https://github.com/SSSD/sssd/pull/84 >> >> The full text of c&p here: > > Hi Fabiano, > > thank you for the design page. > >> >> = Socket Activatable Responders = >> > ... >> KCM >> The KCM responder is only seldom needed, when libkrb5 needs to access > > I'm not sure id 'seldom' is correct here. It will be used by mainly > during authentication but since it might be to default storage for any > Kerberos credential it will be use by the user for any kind of > Kerberos/GSSAPI related authentication to services. > >> the credentials store. At the same time, the KCM responder must be >> running if the Kerberos credentials cache defaults to `KCM`. >> Socket-activating the responder would solve both of these cases. >> > > But my main question is about the monitor and > /var/lib/sss/db/config.ldb. If I understand the design correctly the > monitor will still run and create config.ldb which is good because then > all socket-activated components will see the same config. So a > configuration change required a restart of the monitor. How will the > socket activated services handled in this case. Will the monitor shut > them down or is systemd smart enough to see that the "parent" service is > shut down and will shutdown the children as well. systemd is smart enough to do that, or almost. :-) Having "PartOf=sssd.service" as part of responders' unit files is enough to make then restart/shutdown any time systemd is restarted/shutdown. Best Regards, ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
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/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [2]: https://github.com/SSSD/sssd/pull/84 > > The full text of c&p here: Hi Fabiano, thank you for the design page. > > = Socket Activatable Responders = > ... > KCM > The KCM responder is only seldom needed, when libkrb5 needs to access I'm not sure id 'seldom' is correct here. It will be used by mainly during authentication but since it might be to default storage for any Kerberos credential it will be use by the user for any kind of Kerberos/GSSAPI related authentication to services. > the credentials store. At the same time, the KCM responder must be > running if the Kerberos credentials cache defaults to `KCM`. > Socket-activating the responder would solve both of these cases. > But my main question is about the monitor and /var/lib/sss/db/config.ldb. If I understand the design correctly the monitor will still run and create config.ldb which is good because then all socket-activated components will see the same config. So a configuration change required a restart of the monitor. How will the socket activated services handled in this case. Will the monitor shut them down or is systemd smart enough to see that the "parent" service is shut down and will shutdown the children as well. bye, Sumit ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: > On (29/11/16 10:27), Jakub Hrozek wrote: > >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? This is the question, right? What do we use the private sockets for, like this one: /var/lib/sss/pipes/private/pam as opposed to this one: /var/lib/sss/pipes/pam > >> > > >> >Yes, that's where we route PAM requests started by UID 0 to. > >> > > >> For example. The nss responder need't run as root. > > > >I don't think this is about the identity the responder runs at, but > >about the identity of the client who talks to the responder socket, no? > > > I do not understant. Could you elaborate or provide an example? > Where you can see a problem with pure systemd solution for > unprivileged responders. We need to provide service files anyway. So provided I'm answering the right question :) the logic that routes the PAM request to /var/lib/sss/pipes/private/pam or /var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM application is running as UID 0, then the PAM module writes to SSS_PAM_PRIV_SOCKET_NAME, otherwise it writes to SSS_PAM_SOCKET_NAME. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:30), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:24:03AM +0100, Fabiano Fidêncio wrote: >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik >> 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/sssd-devel@lists.fedorahosted.org/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? > >I guess ideally none, especially some security certifications require >that no code that authenticates users runs as root. But we're not there yet, >see for example: >https://fedorahosted.org/sssd/ticket/3014 it iss not related to responder. >or: >https://fedorahosted.org/sssd/ticket/3099 > it is not related to responder either. >btw now that you nuked the config changing API in IFP, it should be >possible for IFP to drop privileges after it connects to the system bus >(or even before? I'm really not sure anymore). > >Can we have a ticket to examine if we can start IFP as the sssd user? ifp responder can be started with --uid 0 --gid 0 and not with --unprivileged-start. We can convert to unprivileged-start later if possible. So far I cannot see any big issue. Circular dependency between resolving sssd user and files provider and be solved with hardcoded UID GID. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:27), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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. > >I don't think this is about the identity the responder runs at, but >about the identity of the client who talks to the responder socket, no? > I do not understant. Could you elaborate or provide an example? Where you can see a problem with pure systemd solution for unprivileged responders. We need to provide service files anyway. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:24:03AM +0100, Fabiano Fidêncio wrote: > On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? I guess ideally none, especially some security certifications require that no code that authenticates users runs as root. But we're not there yet, see for example: https://fedorahosted.org/sssd/ticket/3014 or: https://fedorahosted.org/sssd/ticket/3099 btw now that you nuked the config changing API in IFP, it should be possible for IFP to drop privileges after it connects to the system bus (or even before? I'm really not sure anymore). Can we have a ticket to examine if we can start IFP as the sssd user? ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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. I don't think this is about the identity the responder runs at, but about the identity of the client who talks to the responder socket, no? > 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 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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? Best Regards, -- Fabiano Fidêncio ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:01), Lukas Slebodnik 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/sssd-devel@lists.fedorahosted.org/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 > Actually we might add new parameter "--unprivileged-start" which would be used for skiping calls of *chown_debug_file* + *become_user* and also maybe checking that process is not executed as root (uid != 0 && gid != 0) LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
fidencio commented:
"""
On Tue, Nov 29, 2016 at 9:33 AM, Pavel Březina
wrote:
> One thing I don't like about those patches is that we always recreate the
> idle timer. Can we get around this (maybe also for the client idle
> timeout)? What I have i mind is this:
>
>1. Instead of resetting the timer, remember time(NULL) of the last
>communication, say last_request_time
>2. Create a periodic timer that fires each responder_idle_timeout / 2
>3. In the timer check that last_request_time + responder_idle_timeout
>< time(NULL)
>
> It won't be as precise as your solution, but I don't think we need it to
> be but it will save us lots of memory operations. What do you think?
>
Fine by me. Your suggestion has been used in a few other places of the our
codebase as well.
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> , or mute
> the thread
>
> .
>
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-263514555
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
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/sssd-devel@lists.fedorahosted.org/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 LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#96][closed] CONFDB: Supress clang false passitive warnings
URL: https://github.com/SSSD/sssd/pull/96 Author: lslebodn Title: #96: CONFDB: Supress clang false passitive warnings Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/96/head:pr96 git checkout pr96 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#96][+Pushed] CONFDB: Supress clang false passitive warnings
URL: https://github.com/SSSD/sssd/pull/96 Title: #96: CONFDB: Supress clang false passitive warnings Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#96][comment] CONFDB: Supress clang false passitive warnings
URL: https://github.com/SSSD/sssd/pull/96 Title: #96: CONFDB: Supress clang false passitive warnings lslebodn commented: """ On (28/11/16 14:13), fidencio wrote: >Acked-by: Fabiano Fidêncio > Thank you for review. master: * 13b1d270fb72cf2c2e18f0b2a59cb424c51f7675 LS """ See the full comment at https://github.com/SSSD/sssd/pull/96#issuecomment-263510851 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
pbrezina commented:
"""
One thing I don't like about those patches is that we always recreate the idle
timer. Can we get around this (maybe also for the client idle timeout)? What I
have i mind is this:
1) Instead of resetting the timer, remember time(NULL) of the last
communication, say `last_request_time`
2) Create a periodic timer that fires each `responder_idle_timeout / 2`
3) In the timer check that `last_request_time + responder_idle_timeout <
time(NULL)`
It won't be as precise as your solution, but I don't think we need it to be but
it will save us lots of memory operations. What do you think?
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-263507800
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
