[ltt-dev] [RFC UST] Processes model

[Nils Carlson]

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

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

/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
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110118/3d40efdc/attachment-0003.htm>