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

[Elvis Angelaccio]

On Sat, Jan 14, 2017 at 11:58 PM, Elvis Angelaccio
<elvis.angelaccio at kde.org> wrote:
> 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

The project idea is now live on the ideas page [1]. I need to tweak
the phabricator tasks, I'll do it later.
Feel free to improve it and/or to sign-up as co-mentors ;)

[1]: https://community.kde.org/GSoC/2017/Ideas#Project:_Polkit_support_in_KIO.2FDolphin

Cheers,
Elvis



>
>
>
> 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