[SSSD] [PATCH] possible alternative for #2071

Jakub Hrozek jhrozek at redhat.com
Mon Sep 9 11:41:39 UTC 2013


On Mon, Sep 09, 2013 at 01:25:30PM +0200, Sumit Bose wrote:
> On Tue, Sep 03, 2013 at 10:52:14PM -0400, Simo Sorce wrote:
> > Attached an untested possible alternative for #2071
> > 
> > The other option is the last patch of my previous patchset in the thread
> > named: "[SSSD] [PATCHES] Simplify credential krb5 cache manipulation".
> > 
> > Let's discuss if any of these  approaches is ok, or if a third way needs
> > to be found.
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York
> 
> (a short summary of the two patches in discussion)
> The difference between the two approaches is that the patch in this
> tread just sets the permission on all newly created directories to
> "new_dir_mode = 0700" making them private by default. The patch in the
> other thread tries to improve the current scheme where SSSD tries to
> figure out which directory which must be created is a public or a
> private one and sets the mode accordingly.
> 
> I agree with 'Setting up public directories is the job of the admin' and
> like the fact that the patch is making the SSSD code much simpler. But I
> assume that there are SSSD setups in use which depend on the feature of
> creating the directories with the "right" permissions. I can imagine
> automatic installations e.g. with kickstart which does not create the
> needed directories but rely on SSSD to create them or installations
> where the credential caches are stored into some RAM based file system
> where directories must be recreated on every restart.  I do not want to
> discuss the correctness of those approaches or if the paths used to
> store the credential caches are chosen wisely my point is just that a
> change might break existing installations.
> 
> For this reason I would prefer to just improve the existing behaviour.
> But if a majority says that it is time for a change I will not argue
> against it.
> 
> bye,
> Sumit

That's a good point.

Could we get away with keeping the existing behaviour and printing a log
message whenever we create a public directory saying that this feature
might go away in a later release?



More information about the sssd-devel mailing list