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

[Aleix Pol]

On Tue, Jan 24, 2017 at 11:59 PM, Elvis Angelaccio
<elvis.angelaccio at kde.org> wrote:
> On Mon, Jan 23, 2017 at 4:15 AM, Aleix Pol <aleixpol at kde.org> wrote:
>> 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
>>>
>>>
>>>
>>> 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 :)
>>
>> This is interesting.
>>
>> You'd have 1 helper per call?
>
> Well, one kauth action per call. But yes, that means one helper
> process spawned per call, right?

I'm pretty sure you can have different actions in the same helper.

> I don't think this is going to be a problem, I think the average
> Dolphin user just wants to (e.g.) remove one or few files at the same
> time.

While your motivation is Dolphin, this will be used by many other
applications. I think it's worth taking that into account and giving
it some thought.

>> Also do we see this as full support of privileged access or just some
>> helpers?
>
> I'm not sure what you mean here, can you expand?

Well the question was if you'd want this GSoC (remember, ~3 solid
months of work) for a full mapping of the file kioslave for actions to
be ran as root, or just few actions.

By your reply I understand you're leaning towards supporting whatever
seems necessary. Which can make sense.

>> What do you see happening on more complex and delicate things
>> like reading and writing files?
>
> I think we can even skip the reading case? Either the file is
> world-readable, or it's a file in /var or /proc or whatever and we
> probably don't want Dolphin users to touch it...

If you implement reading, your Dolphin users will be able to do
something with the files when they click on them (as kwrite will be
able to read the contents).

> What we need in the helper is just the writing case imho. Given that
> FileProtocol::copy() is quite complex, to avoid code duplication in
> the helper we could refactor and move that code to a private library
> that would be used both in copy() and the helper action.

HTH,
Aleix