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