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

[Elvis Angelaccio]

On Wed, Jan 25, 2017 at 3:43 AM, Aleix Pol <aleixpol at kde.org> wrote:
> 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.

Yep that's what I meant, one helper with many actions.

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

Sure. I do have some open questions.
In particular, let's say someone is using KIO::del() inside a loop:

* Does polkit cache the password? Or the user needs to type it again
in the next loop iteration?
* If kauth spawns a process for every iteration, is this going to be a
problem with huge loops?

We could also make the whole thing opt-in, if we want to play safe.
Something like:

auto job = KIO::del(...);
job->addMetaData("kauth", "true");

and then the file ioslave only calls the helper if it finds the
metadata above set to true.

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

Ok I see it now. Yes, the latter (hopefully...)

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

Right. Well the reading case is very similar to writing, after all.
Should be doable, indeed :)

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

Cheers,
Elvis