Re: [SSSD] [PATCH] possible alternative for #2071
On Mon, 2013-09-09 at 13:41 +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?
I do not really think it is a good point.
A) I really do not think there is any user fo this feature, the only 2
places where people put stuff today are /tmp (FILE or DIR) and /run/user
(DIR).
/tmp is already set up correctly (if not many other things will break
and SSSD should *not* mask the mess by creating the dir and further
confusing the admin.
/run/user is a private directory so making it public would be wrong.
I think a change of behavior is in the best interest of our community
even if it ends up breaking 1 rare install that happened to know of this
new behavior and intentionally used it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York