It was <2013-10-14 pon 15:22>, when Jussi Laako wrote:
> On 11.10.2013 19:30, Schaufler, Casey wrote:
>>
>> Dominique and I discussed the underlying problem in some detail
>> and believe that we have a cleaner solution.
>
> Nobody has yet explained why launcher needs to be somehow privileged
> and why it's not just a service part of a normal user session?
>
> I'm not advocating for SO_PEERCRED & /proc/PID usage, but it can be
> made fairly proper. I have made a small demo client/server pair
> (attached) that should be quite OK for dealing with this combination
> for whatever use.
>
> I think I will also attempt to fix kernel regarding the "feature" I
> found (as commented in the sources).

I haven't followed the thread very closely. If I understand the problem
correctly the patch[fn:1] proposed by Jan Kaluza and discussed[fn:2] on
RedHat's bugzilla might help. It introduces three new socket-level
control messages: SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP that are meant
to provide information about processes to systemd journal.

Systemd journal logs not only messages sent by processes but also
information about processes themselves. The goal is to provide some
trusted information that cannot be altered by the clients which send the
message. Currently it reads a few /proc/<PID>/* files upon every message
received, which brings a noticable performance hit. The socket control
messages are meant to be more efficient, less racy and as secure as
/proc.

Footnotes:

[fn:1] https://lkml.org/lkml/2013/8/27/318

[fn:2] https://bugzilla.redhat.com/show_bug.cgi?id=963620

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Attachment: pgpEp9yBxDMK3.pgp
Description: PGP signature

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to