On Mon, Sep 09, 2013 at 01:41:39PM +0200, Jakub Hrozek wrote:
> 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?

Good idea, if we do not change it right away we should at least declare
it deprecated.

bye,
Sumit
> _______________________________________________
> sssd-devel mailing list
> sssd-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to