D15718: Do not index the path if the path has no execute permissions.

[James Smith]

smithjd added a comment.


  In D15718#330845 <https://phabricator.kde.org/D15718#330845>, @ngraham wrote:
  
  > In D15718#330844 <https://phabricator.kde.org/D15718#330844>, @smithjd wrote:
  >
  > > In D15718#330836 <https://phabricator.kde.org/D15718#330836>, @ngraham wrote:
  > >
  > > > Wouldn't this have the effect of un-indexing most files? A quick check of my documents (text, word processing, excel, etc) reveals that none of them have the execute bit set. As-is, I think this would render Baloo mostly useless.
  > >
  > >
  > > A default mask of 0002 or more permissive looks fairly common across distros, and is permissive enough to index files by default.
  > >
  > > setfacl -d -m u::rwx ~ or umask 0022 will set default execute permissions on created files. You can set something less permissive on your downloads directory or plasma vault mount with setfacl -d u::rw or similar.
  > >
  > > chmod -R 755 ~ will recursively give every file in your home directory execute permisions.
  >
  >
  > You are proposing fundamentally breaking Baloo and then requiring that users or distros clean up our mess for us by making all their files executable--in the process reducing their own security. Sorry, but this is simply unacceptable.
  >
  > No part of this proposal makes any sense to me. We just can't do this.
  
  
  Folders with the execute bit off already won't allow their contents listed. How wouldn't this convention be useful extended to prevent a file from being listed in Baloo's database?
  
  How does setting files executable lead to reduced security? Some common folders may end up needing more restrictive defaults (downloads for instance) and the problem of potentially indexing sensitive information or feeding an extractor a specially crafted file designed to exploit a bug in it will have been mediated to some extent.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D15718

To: smithjd, ngraham, #baloo
Cc: bruns, ngraham, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180924/efec1749/attachment-0001.html>