[KPhotoAlbum] KPA 5.1 issue list

[Robert Krawitz]

On Fri, 30 Dec 2016 23:29:42 +0100, Johannes Zarl-Zierl wrote:
> On Mittwoch, 28. Dezember 2016 19:15:50 CET Tobias Leupold wrote:
>> > 4. At least in one install, parts of the menu entries had been missing,
>> > due to missing permissions on
>> > /usr/local/share/kphotoalbum
>> > /usr/local/etc/xdg/kphotoalbumrc
>> > (and sub dirs in the path)
>> > Note that I build as a normal user, but install as 'root'.
>> > At the same time my root account has a limited umask (077) set.
>> > I guess the install process should give explicit permissions, instead of
>> > relying on umask or the one already present on installed files.
>> 
>> Probably also a porting issue. Interestingly, no bug concerning this was
>> filed yet – I don't think anything about the install process was changed.
>> But it's Johannes who's the cmake expert.
>
> There's not much that we can do w.r.t. permissions. CMake docs state:
> "Files [...] are by default given permissions OWNER_WRITE, OWNER_READ, GROUP_READ, and WORLD_READ if no PERMISSIONS argument is given."
>
> [source:
> https://cmake.org/cmake/help/v3.7/command/install.html#installing-files]
>
> That means that even if we set this explicitly, your umask will probably interfere in the same way. Do you have the same problem with other cmake-based installers?

kpa's doing the right thing.  It shouldn't override your umask.  For
all the installer knows, you *want* it to be accessible to very few
people.  If you want it to be world accessible, set your umask to
something appropriate for that.

I remember 30 years ago the makefile for GNU Emacs copied the Lisp
files from the source directory into the installation directory,
forcibly giving world write access to everyone.  This wasn't a
mistake; this was a deliberate decision to try to encourage a form of
software freedom where all users of the system were encouraged to play
around.  I'm as pro free software as anyone, but this was just
absurd.  The attitude toward security at the time was pretty lax, but
we sure weren't going to allow 1000 undergrads to edit the emacs lisp
files for everyone to their heart's content.

There are good reasons for package maintainers not to try to enforce
policies that are properly installation-dependent.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton