Looking for co-mentors for a GSoC Dolphin/KIO project

[Elvis Angelaccio]

Hi,
I played a bit with kauth in the file ioslave [1] and everything seems
to work nicely :)
[2] is a patch for kio that allows to delete file:// URLs upon polkit
authentication.

The helper just calls unlink(). In the patch I call the helper (from
the ioslave) only if unlink() failes with EACCES or EPERM errors.
This could be seen as code duplication (because we have unlink in two
places), one of the things Aleix was afraid of. On the other hand, why
call an helper process if you don't need it?

Cheers,
Elvis

[1]: https://phabricator.kde.org/T5070
[2]: https://phabricator.kde.org/file/data/mcjxwtqj2hijhebldlgb/PHID-FILE-ceznjt2trea7lli6v5n6/kauth.diff



On Sun, Jan 8, 2017 at 8:32 PM, Elvis Angelaccio
<elvis.angelaccio at kde.org> wrote:
> On Sun, Jan 8, 2017 at 8:14 PM, Aleix Pol <aleixpol at kde.org> wrote:
>> On Sun, Jan 8, 2017 at 7:48 PM, Elvis Angelaccio
>> <elvis.angelaccio at kde.org> wrote:
>>> Hi David and everyone,
>>> GSoC 2017 is near and it's time to discuss project ideas.
>>> This year I want to tackle one of the biggest problems in Dolphin:
>>> lack of polkit support. Dolphin users often don't know how to use the
>>> command line, so when they have to move root-owned files around they
>>> are forced to start Dolphin with root permissions, which is bad and
>>> dangerous.
>>>
>>> GSoC is a great opportunity and I'm confident we can find an awesome
>>> student who will fix this. :)
>>>
>>> I started a draft of the project idea in [1] and I'm looking for
>>> co-mentors and feedback.
>>> In particular @David:
>>> 1) Am I right to claim that KAuth support needs to go only in the file
>>> protocol? i.e. basically refactor into KAuth actions the parts of
>>> file.cpp and file_unix.cpp where the actual interaction with the
>>> filesystem happens.
>>> 2) Is this even possible from a techical point of view? Or maybe KAuth
>>> and ioslaves don't play well together?
>>>
>>> You should be able to edit the shared document, I hope. Please let me
>>> know if that's not the case.
>>>
>>> Cheers,
>>> Elvis
>>>
>>> [1]: https://share.kde.org/index.php/s/bRBrrkOkuSCbkhT
>>
>> Hi Elvis,
>> This is a good idea and I see tha it can be useful. I see some
>> problems though, that could lead the wrong people to the task.
>>
>> How do we want to implement this? Do we want to be able to run
>> kioslaves as root? Or do we want to Implement kauth/policykit support
>> in the file kioslave?
>
> Yes, kauth in the file kioslave is what I was thinking. Running the
> whole kioslave as root sounds dangerous indeed.
>
>> In either case, no modifications in Dolphin should be required. I'm
>> leaning towards the latter, though.
>>
>> I think it could be interesting to think about the security
>> implications it would have to have a file kio that can escalate to
>> root, note that this will extend to all applications that use KIO, not
>> just dolphin.
>
> Yep indeed. The file slave should only delegate the minimal amount of
> work necessary to the root helper (this probably needs some
> refactoring).
>
>>
>> Also if this is not done properly, we could end up with the whole kio
>> file duplicated into a kauth helper. I'd say it's worth investigating
>> how the student will implement this. It's well-known by now that it's
>> not the best idea to have the students design the approach they'll
>> take.
>
> Right, the approach definitely needs to be clear before the student
> starts. Also because this project involves kio, ioslaves, kdeinit,
> kauth...
> Really easy to get lost in all this stuff for a new contributor :)
>
>>
>> HTH,
>> Aleix
>
> Cheer
> Elvis