[ltt-dev] [RFC UST] Processes model

[David Goulet]

On 11-01-18 01:28 PM, Nils Carlson wrote:
> Replying from home...
>
> On Jan 18, 2011, at 6:29 PM, David Goulet wrote:
>
>> First, let me say! This is a very impressive reply!
>>
>> Thanks a lot for taking that time!
>>
>> Comments below (in order to make things going!)
>>
>> On 11-01-18 05:24 AM, Nils Carlson wrote:
>>>>
>>>> ustd - Main daemon that act as a trace session registry
>>> I would name this ust-sessiond, mostly because ustd has already been used
>>> and it might be good to not reuse the name.
>>>
>>
>> Agree. Since it will only manage session, it makes perfect sense.
>>
>>>> An ID SHOULD be a unique hash of the session name, trace path name,
>>>> date/time, PID and/or UID
>>>>
>>> What is the ID used for?
>>
>> Since an application can be trace multiple time, the PID and trace
>> name are the only things that makes them "unique". So, the idea of the
>> ID is to be able for the user to interact with is trace without these
>> information. It's a bit inspired by "screen" when you want to attach
>> to a session :
>>
>> There are several suitable screens on:
>> 14864.pts-10.raoul(11-01-18 11:46:21 AM)(Attached)
>> 14820.pts-2.raoul(11-01-18 11:46:18 AM)(Attached)
>> Type "screen [-d] -r [pid.]tty.host" to resume one of them.
>>
>> That would be the kind og output that ust-sessiond sent you when you
>> list the active session by you client control (ustctl).
>>
>
> Ok, this is basically a pidunique... but maybe shorter?

Yep sure it could be 8 characters long...

>>> Figure 4 ustctl starts a trace, telling the sessiond what
>>> the name of the trace should be, which application pid and what
>>> consumer it
>>> wants.
>>
>> Confuse here by "what consumer it wants"... how the application will
>> do that and knows?
>
> Well, we skipped a bunch of steps... At one point we will have some more
> commands:
> ustctl create-trace <pid> <trace name>
> ustctl list-consumers
> ustctl select-consumer <pid> <trace-name> <consumer-name>
>
> or some such.

I see. Easier to integrate other kind of consumer also that way (gdb 
might be a consumer or tcf library).

>>
>>>
>>> Figure 7 trace still starting, app allocates buffers in shared memory
>>> and passes
>>> each to the consumerd. The consumerd now maps each of them in turn and
>>> checks which
>>> cpu the belong to and passes them to the corresponding cpu thread where
>>> they are added
>>> to the epoll set.
>>>
>>> +---------------+ +--------+
>>> | ust-consumerd |<-map buffers-| app_1 |
>>> +---------------+ +---+----+
>>>
>>>
>>> 3. If we want to implement access control we can do it by passing
>>> credentials across the socket (see man unix). These can then be used
>>> by both the consumerd to open files in the right places with the right
>>> credentials. DBUS does this. We don't want to re-implement DBUS though.
>>>
>>
>> I would argue here that this is a bit trickier then that. Let's see if
>> I understand correctly what you are saying:
>>
>> application allocates the buffers and set uid and gid to the app user.
>> (Ex: uid:mysql and gid:mysql).
>>
>> ust-consumerd has to be run as a privilege user to access applications
>> buffers OR the buffers are set on read for everyone... which WE DON'T
>> want. Also, if ust-consumerd want to write to disk using the app
>> credentials, again privilege user is needed.
>>
>> However, this brings up two problems:
>>
>> 1) I will suppose that the data on disk is set with the credentials of
>> the user that requested tracing (Ex: nils) in order to be able to read
>> it. If not, mysql:mysql will be used (using the app credentials) and
>> "nils" will not be able to read the data.
>>
>> 2) This kind of architecture makes EVERY user on the machine being
>> able to trace EVERY application... This is a behavior that we want to
>> avoid with that re-engineering. Either ust-sessiond control the access
>> based on the UID/GID (bad..) or the file system does it for us (good)
>>
>> So this is why ust-sessiond was allocating the shared memory in order
>> to set the "tracing" group so we could have a bit of control over that.
>>
>> We could easily change that to ust-consumerd doing that but...
>> again... some kind of privileges are needed to set the tracing group.
>>
>> I hope I put it clearly enough here :S ... the whole point of having a
>> consumerd per apps was the access rights on the buffers and trace
>> data. Having a central consumerd, I agree however it makes that daemon
>> run as a privilege user to manage the right credentials.
>
> Hmm.. lets sort things out from basics.
>
> app has cred A
> user has cred B
> consumer has cred C
>
> We want consumer to access the apps allocated buffers, it can do this by
> getting credentials from the app over a unix socket and then doing a
> setuid while opening the buffers, once buffers are open I believe uid
> isn't an issue, authentication is done at open time and never after as
> far as I know.
> We want the user to be able to access the files which the consumer
> outputs, this can be done by sending the users credentials over a unix
> socket to the consumer, and the consumer does setuid while opening the
> files...
>

That way, ust-consumerd cannot setuid from an unprivileged user to 
another one. consumer with cred C cannot setuid(A). In order to make it 
works, ust-consumerd will have to be root or to have special capabilities.

Also, this means that any user can get the trace data from any 
application that way right?

Once it open, yes no more auth. is done after that.

> Am I missing something here?
>
>>
>>>> The new "lttngtrace" command line tool MUST be use to interact with
>>>> the ustd
>>>> registry daemon for every trace action needed by the user.
>>>
>>> We currently have a library (libustcmd) for this? ustctl wraps
>>> libustcmd. I have
>>> a small plan of renaming the library libustctl because it sounds better.
>>>
>>> The library has to stay as it will in not too distant a future be used
>>> to implement
>>> RPC calls to ust using tcf or some such.
>>
>> The plan is to get a "strace" tool alike for tracing ust and/or lttng.
>> libustctl is here to stay and lttngtrace will interface with it and
>> lttctl and lttv text dump also.
>>
>
> Ok, so lttngtrace will run on ust and lttng. Thats fine. But just don't
> compromise ust in any way...

It was never the plan to modify the library. It's command line tool that 
will ONLY interact with the appropriate library such as libustctl :)

David

>
> /Nils
>
>> However, we should discuss this within another thread. Mathieu and I
>> will put some development effort in that so we have to get on the same
>> page with you at least for UST!
>>
>> Thanks again!
>> David
>>
>> --
>> David Goulet
>> LTTng project, DORSAL Lab.
>>
>> PGP/GPG : 1024D/16BD8563
>> BE3C 672B 9331 9796 291A 14C6 4AF7 C14B 16BD 8563
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca <mailto:ltt-dev at lists.casi.polymtl.ca>
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563