[ltt-dev] [RFC UST] Processes model
nils.carlson at ludd.ltu.se
Tue Jan 18 13:28:37 EST 2011
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
> 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
ustctl create-trace <pid> <trace name>
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
>> checks which
>> cpu the belong to and passes them to the corresponding cpu thread
>> 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
>> credentials. DBUS does this. We don't want to re-implement DBUS
> 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
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
>> The library has to stay as it will in not too distant a future be
>> 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...
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lttng-dev