[ltt-dev] [RFC UST] Processes model

[Nils Carlson]

On Jan 18, 2011, at 9:21 PM, David Goulet wrote:

>
>
> On 11-01-18 03:14 PM, Nils Carlson wrote:
>>
>> On Jan 18, 2011, at 7:47 PM, David Goulet wrote:
>>
>>>
>>>
>>> On 11-01-18 01:28 PM, Nils Carlson wrote:
>>>> Replying from home...
>>>>
>>>> On Jan 18, 2011, at 6:29 PM, David Goulet wrote:
>>>>
>>>>
>>>> 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.
>>>
>>
>> Yepp, CAP_SETUID or something...
>
> Yep but we need a special user for ust-consumerd in that case.
>
> This is exactly why the 1 app <-> 1 consumer was proposed to make  
> consumerd NOT root and with the user credentials and tracing group.
>
>>> Also, this means that any user can get the trace data from any
>>> application that way right?
>>>
>>
>> Well, in order to connect to the consumer and the app and so on they
>> have to go via the sessiond, so we could enforce whatever policy  
>> there
>> that we want there.
>
> Exactly, this is why the sessiond should keep the UID/GID of the  
> user and the apps in order to at least have a small control over  
> access control.
>
> I looked at the SO_PASSCRED of the socket API. Very nice to know!!  
> Very nice way of getting user credential from lttngtrace and the apps.
>

Well, there are other options... Such as the consumer memory mapping  
for the benefit of the application and libustctl creating the files and
sending the file descriptors, but these complicate the design quite a  
bit I feel.

Is the CAP_SETUID such a big problem?

/Nils

> David
>
>>
>> /Nils
>
> -- 
> David Goulet
> LTTng project, DORSAL Lab.
>
> PGP/GPG : 1024D/16BD8563
> BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563