dfaure added a comment.

  Indeed the sender could definitely fake the PID.
  One could generate and send a sha1 and store it in the slave (and send it as 
metadata with every command), but this can still be sniffed.
  I assume the KAuth security principle is that an intruder (who would have 
access to your session, and therefore can do a lot of things already, including 
installing a keylogger), shouldn't be able to get root access?
  In that case, either kio_file should lose priviledges immediately (sounds 
annoying for the user, but maybe that's the price of this feature?), or the app 
(libkio) should perform the file operations directly.
  I'm surprised you didn't hit that yet, btw. E.g. deleting local files, will 
not involve kio_file. DeleteJobPrivate::deleteNextFile calls QFile::remove() 
directly. Of course this isn't the case for all file operations (otherwise your 
patch wouldn't work at all), and it might not even be a good idea to generalize 
this (it's already visible that deleting a 6 GB local file will freeze the app, 
because of this - which was written under the assumption that deleting is fast).
  Brainstorming further: the other possibility is that kio_file processes that 
gained root auth, cannot be reused by another app later on. This could be done 
somehow in the KIO scheduler or in klauncher, if they can be told that this 
slave should be killed rather than reused once idle. The design of that stuff 
isn't fully clear in my mind (I didn't write that part), but make sure not to 
get confused by "idle slave which is associated to my process" 
(KIO::Scheduler's IdleJob, kills the slave after 3 minutes), and "idle slave 
that has been returned to klauncher" (in frameworks/kinit), for use by another 
process (or killed after 30s). But I can't find the code that returns an idle 
slave to klauncher (only a "slave that has been put on hold", which is a 
different use case (documented in kio/docs/krun-passing-slaves.txt).

  R241 KIO


To: chinmoyr, #frameworks, dfaure, fvogt
Cc: markg, anthonyfieroni, michaelh

Reply via email to