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
[email protected] <mailto:[email protected]>
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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
