All of lore.kernel.org
 help / color / mirror / Atom feed
* Sending the FD over D-bus
@ 2019-04-09 19:47 Ratan Gupta
  2019-04-10  2:13 ` William Kennington
  2019-04-11  7:51 ` vishwa
  0 siblings, 2 replies; 10+ messages in thread
From: Ratan Gupta @ 2019-04-09 19:47 UTC (permalink / raw)
  To: Tanous, Ed, bradleyb, openbmc

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hi All,

As Discussed in yesterday community call, I did some POC to send the 
unix FD object over the D-Bus.

BackGround: We are exploring the possibilities how to send the secrets 
from one process to other process,

a) If the IPC is D-bus

b) Calling process doesn't have the root permission to write the secrets 
in the configuration file.

One of the proposal came, Can the calling process  send the unix fd over 
the D-Bus instead of sending the actual password

and receiving process reads the data from the sent fd.?

There was a confusion if some other app can snoop the D-bus message and 
get the FD and read it.I tried to simulate the same

behavior in the POC but not sure whether it is correct or not.

This POC has two files which is attached with this mail.

Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the 
unix fd as parameter reads it and send the data back

Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, then 
opens the file and send the fd over D-bus.


After sending the data over D-bus , I introduced a sleep of 15 sec so 
that I can try to open the same fd from other

process,I open the python shell and try to open the shared FD but 
couldn't open it.

Ratan













[-- Attachment #2: dbus-client-fd-test.py --]
[-- Type: text/x-python, Size: 993 bytes --]

import unittest
import time

import dbus
import dbus.service
import dbus.glib

class TestCase(unittest.TestCase):

    def setUp(self):
        # WRITE SOMETHING IN THE FILE AND
        # close it
        f = open("/tmp/fd-test", "w")
        f.write("Hello, World!")
        f.close();


    def testHelloService(self):
        bus = dbus.SessionBus()
        service = bus.get_object('test.readFDservice', '/test/readFDservice')
        method = service.get_dbus_method('readFD', 'test.readFDservice')
        # Have written the hello world in the fd-test file, open the file and
        # send the fd over D-bus.
        f = open('/tmp/fd-test')
        print ("fd = %d" % f.fileno())
        fds = {0:dbus.types.UnixFd(f)}
        r = method("Test", fds)
        time.sleep(60) #To invoke another prg to try to read the shared fd.
        f.close()

        print ("r = %s" % r)
        assert r == "Hello, World!" # we got the same string


if __name__ == '__main__':
    unittest.main()

[-- Attachment #3: dbus-service-fd-test.py --]
[-- Type: text/x-python, Size: 782 bytes --]

import os

import dbus
import dbus.service
import dbus.glib
import gobject

class ReadFDService(dbus.service.Object):

    def __init__(self):
        bus_name = dbus.service.BusName('test.readFDservice', bus = dbus.SessionBus())
        dbus.service.Object.__init__(self, bus_name, '/test/readFDservice')

    def listen(self):
        loop = gobject.MainLoop()
        loop.run()

    @dbus.service.method('test.readFDservice', in_signature="sa{uh}")
    def readFD(self, serviceName, fds):
        print ([type(param) for param in (serviceName, fds)]  )
        print ("serviceName: %s" % serviceName)
        print ("fd: %s" % fds)
        r = os.fdopen(fds[0].take()).read()
        return r


if __name__ == '__main__':

    myservice = ReadFDService()
    myservice.listen()

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-09 19:47 Sending the FD over D-bus Ratan Gupta
@ 2019-04-10  2:13 ` William Kennington
  2019-04-10  4:53   ` Deepak Kodihalli
  2019-04-11  7:51 ` vishwa
  1 sibling, 1 reply; 10+ messages in thread
From: William Kennington @ 2019-04-10  2:13 UTC (permalink / raw)
  To: Ratan Gupta; +Cc: Tanous, Ed, Brad Bishop, openbmc

What is the issue with just sending them over d-bus? The only party
that can view the messages outside of the normal unicast partner is
the dbus-broker process. You are still trusting the dbus-broker in the
file descriptor case. On top of that you are probably still trusting
the mapper to give you the correct service name prior to sending the
secrets.

On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>
> Hi All,
>
> As Discussed in yesterday community call, I did some POC to send the
> unix FD object over the D-Bus.
>
> BackGround: We are exploring the possibilities how to send the secrets
> from one process to other process,
>
> a) If the IPC is D-bus
>
> b) Calling process doesn't have the root permission to write the secrets
> in the configuration file.
>
> One of the proposal came, Can the calling process  send the unix fd over
> the D-Bus instead of sending the actual password
>
> and receiving process reads the data from the sent fd.?
>
> There was a confusion if some other app can snoop the D-bus message and
> get the FD and read it.I tried to simulate the same
>
> behavior in the POC but not sure whether it is correct or not.
>
> This POC has two files which is attached with this mail.
>
> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
> unix fd as parameter reads it and send the data back
>
> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, then
> opens the file and send the fd over D-bus.
>
>
> After sending the data over D-bus , I introduced a sleep of 15 sec so
> that I can try to open the same fd from other
>
> process,I open the python shell and try to open the shared FD but
> couldn't open it.
>
> Ratan
>
>
>
>
>
>
>
>
>
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-10  2:13 ` William Kennington
@ 2019-04-10  4:53   ` Deepak Kodihalli
  2019-04-10  4:58     ` Deepak Kodihalli
  0 siblings, 1 reply; 10+ messages in thread
From: Deepak Kodihalli @ 2019-04-10  4:53 UTC (permalink / raw)
  To: openbmc

On 10/04/19 7:43 AM, William Kennington wrote:
> What is the issue with just sending them over d-bus? The only party
> that can view the messages outside of the normal unicast partner is
> the dbus-broker process. You are still trusting the dbus-broker in the
> file descriptor case. On top of that you are probably still trusting
> the mapper to give you the correct service name prior to sending the
> secrets.


+1


Ratan,

In case bmcweb makes a D-Bus method call to phosphor-user-manager, and 
one of the args of that method call is the password, is the value of 
that argument even visible to other processes connected to the system 
bus? If it is, two processes can talk to each other directly using 
libdbus, that wouldn't even involve the system d-bus daemon/dbus-broker 
I guess.

Regards,
Deepak

> On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>>
>> Hi All,
>>
>> As Discussed in yesterday community call, I did some POC to send the
>> unix FD object over the D-Bus.
>>
>> BackGround: We are exploring the possibilities how to send the secrets
>> from one process to other process,
>>
>> a) If the IPC is D-bus
>>
>> b) Calling process doesn't have the root permission to write the secrets
>> in the configuration file.
>>
>> One of the proposal came, Can the calling process  send the unix fd over
>> the D-Bus instead of sending the actual password
>>
>> and receiving process reads the data from the sent fd.?
>>
>> There was a confusion if some other app can snoop the D-bus message and
>> get the FD and read it.I tried to simulate the same
>>
>> behavior in the POC but not sure whether it is correct or not.
>>
>> This POC has two files which is attached with this mail.
>>
>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
>> unix fd as parameter reads it and send the data back
>>
>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, then
>> opens the file and send the fd over D-bus.
>>
>>
>> After sending the data over D-bus , I introduced a sleep of 15 sec so
>> that I can try to open the same fd from other
>>
>> process,I open the python shell and try to open the shared FD but
>> couldn't open it.
>>
>> Ratan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-10  4:53   ` Deepak Kodihalli
@ 2019-04-10  4:58     ` Deepak Kodihalli
  2019-04-10  6:16       ` Ratan Gupta
  0 siblings, 1 reply; 10+ messages in thread
From: Deepak Kodihalli @ 2019-04-10  4:58 UTC (permalink / raw)
  To: openbmc

On 10/04/19 10:23 AM, Deepak Kodihalli wrote:
> On 10/04/19 7:43 AM, William Kennington wrote:
>> What is the issue with just sending them over d-bus? The only party
>> that can view the messages outside of the normal unicast partner is
>> the dbus-broker process. You are still trusting the dbus-broker in the
>> file descriptor case. On top of that you are probably still trusting
>> the mapper to give you the correct service name prior to sending the
>> secrets.
> 
> 
> +1
> 
> 
> Ratan,
> 
> In case bmcweb makes a D-Bus method call to phosphor-user-manager, and 
> one of the args of that method call is the password, is the value of 
> that argument even visible to other processes connected to the system 
> bus? If it is, two processes can talk to each other directly using 
> libdbus, that wouldn't even involve the system d-bus daemon/dbus-broker 
> I guess.
> 
> Regards,
> Deepak


https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/19409/1/xyz/openbmc_project/User/Ldap/Config.interface.yaml 
- the password here is a property, I guess that's the concern. Could the 
API instead be a method call taking the password - with that it would 
just be the two processes (and d-bus broker) that would have visibility 
to this.

Regards,
Deepak

>> On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta 
>> <ratagupt@linux.vnet.ibm.com> wrote:
>>>
>>> Hi All,
>>>
>>> As Discussed in yesterday community call, I did some POC to send the
>>> unix FD object over the D-Bus.
>>>
>>> BackGround: We are exploring the possibilities how to send the secrets
>>> from one process to other process,
>>>
>>> a) If the IPC is D-bus
>>>
>>> b) Calling process doesn't have the root permission to write the secrets
>>> in the configuration file.
>>>
>>> One of the proposal came, Can the calling process  send the unix fd over
>>> the D-Bus instead of sending the actual password
>>>
>>> and receiving process reads the data from the sent fd.?
>>>
>>> There was a confusion if some other app can snoop the D-bus message and
>>> get the FD and read it.I tried to simulate the same
>>>
>>> behavior in the POC but not sure whether it is correct or not.
>>>
>>> This POC has two files which is attached with this mail.
>>>
>>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
>>> unix fd as parameter reads it and send the data back
>>>
>>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, then
>>> opens the file and send the fd over D-bus.
>>>
>>>
>>> After sending the data over D-bus , I introduced a sleep of 15 sec so
>>> that I can try to open the same fd from other
>>>
>>> process,I open the python shell and try to open the shared FD but
>>> couldn't open it.
>>>
>>> Ratan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-10  4:58     ` Deepak Kodihalli
@ 2019-04-10  6:16       ` Ratan Gupta
  2019-04-10  9:20         ` William Kennington
  0 siblings, 1 reply; 10+ messages in thread
From: Ratan Gupta @ 2019-04-10  6:16 UTC (permalink / raw)
  To: Deepak Kodihalli, Wak, openbmc


On 10/04/19 10:28 AM, Deepak Kodihalli wrote:
> On 10/04/19 10:23 AM, Deepak Kodihalli wrote:
>> On 10/04/19 7:43 AM, William Kennington wrote:
>>> What is the issue with just sending them over d-bus? The only party
>>> that can view the messages outside of the normal unicast partner is
>>> the dbus-broker process. You are still trusting the dbus-broker in the
>>> file descriptor case. On top of that you are probably still trusting
>>> the mapper to give you the correct service name prior to sending the
>>> secrets.
>>
>>
Ed, Richard mention that sending the secrets over D-bus is a security 
concern like some compromised application on the

bmc can watch the D-bus traffic and get the secrets.

>> +1
>>
>>
>> Ratan,
>>
>> In case bmcweb makes a D-Bus method call to phosphor-user-manager, 
>> and one of the args of that method call is the password, is the value 
>> of that argument even visible to other processes connected to the 
>> system bus?
    yes whether it is a D-Bus method call or the D-Bus object having 
properties both are same, any application can watch it.
>> If it is, two processes can talk to each other directly using 
>> libdbus, that wouldn't even involve the system d-bus 
>> daemon/dbus-broker I guess.
I have to experiment that over libdbus, I haven't done that but seems 
p2p binding is there with Qt, not sure witrh sd-bus.
>>
>> Regards,
>> Deepak
>
>
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/19409/1/xyz/openbmc_project/User/Ldap/Config.interface.yaml 
> - the password here is a property, I guess that's the concern. Could 
> the API instead be a method call taking the password - with that it 
> would just be the two processes (and d-bus broker) that would have 
> visibility to this.
>
> Regards,
> Deepak
>
>>> On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta 
>>> <ratagupt@linux.vnet.ibm.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> As Discussed in yesterday community call, I did some POC to send the
>>>> unix FD object over the D-Bus.
>>>>
>>>> BackGround: We are exploring the possibilities how to send the secrets
>>>> from one process to other process,
>>>>
>>>> a) If the IPC is D-bus
>>>>
>>>> b) Calling process doesn't have the root permission to write the 
>>>> secrets
>>>> in the configuration file.
>>>>
>>>> One of the proposal came, Can the calling process  send the unix fd 
>>>> over
>>>> the D-Bus instead of sending the actual password
>>>>
>>>> and receiving process reads the data from the sent fd.?
>>>>
>>>> There was a confusion if some other app can snoop the D-bus message 
>>>> and
>>>> get the FD and read it.I tried to simulate the same
>>>>
>>>> behavior in the POC but not sure whether it is correct or not.
>>>>
>>>> This POC has two files which is attached with this mail.
>>>>
>>>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
>>>> unix fd as parameter reads it and send the data back
>>>>
>>>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, 
>>>> then
>>>> opens the file and send the fd over D-bus.
>>>>
>>>>
>>>> After sending the data over D-bus , I introduced a sleep of 15 sec so
>>>> that I can try to open the same fd from other
>>>>
>>>> process,I open the python shell and try to open the shared FD but
>>>> couldn't open it.
>>>>
>>>> Ratan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-10  6:16       ` Ratan Gupta
@ 2019-04-10  9:20         ` William Kennington
  0 siblings, 0 replies; 10+ messages in thread
From: William Kennington @ 2019-04-10  9:20 UTC (permalink / raw)
  To: Ratan Gupta; +Cc: Deepak Kodihalli, openbmc

On Tue, Apr 9, 2019 at 11:16 PM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>
>
> On 10/04/19 10:28 AM, Deepak Kodihalli wrote:
> > On 10/04/19 10:23 AM, Deepak Kodihalli wrote:
> >> On 10/04/19 7:43 AM, William Kennington wrote:
> >>> What is the issue with just sending them over d-bus? The only party
> >>> that can view the messages outside of the normal unicast partner is
> >>> the dbus-broker process. You are still trusting the dbus-broker in the
> >>> file descriptor case. On top of that you are probably still trusting
> >>> the mapper to give you the correct service name prior to sending the
> >>> secrets.
> >>
> >>
> Ed, Richard mention that sending the secrets over D-bus is a security
> concern like some compromised application on the
>
> bmc can watch the D-bus traffic and get the secrets.
>
Yes, if you are root you can monitor the system bus and read the
secrets, but you can also load kernel modules and read process memory
for any process on the system. If we just ran daemons as unprivileged
users with access to the hardware resources they needed we wouldn't
have this problem. Untrusted, unprivileged programs can write into the
objectmapper right now anyway. I just don't want to see us create a
more complicated system that gives no actual security benefit.
> >> +1
> >>
> >>
> >> Ratan,
> >>
> >> In case bmcweb makes a D-Bus method call to phosphor-user-manager,
> >> and one of the args of that method call is the password, is the value
> >> of that argument even visible to other processes connected to the
> >> system bus?
>     yes whether it is a D-Bus method call or the D-Bus object having
> properties both are same, any application can watch it.
> >> If it is, two processes can talk to each other directly using
> >> libdbus, that wouldn't even involve the system d-bus
> >> daemon/dbus-broker I guess.
> I have to experiment that over libdbus, I haven't done that but seems
> p2p binding is there with Qt, not sure witrh sd-bus.
> >>
> >> Regards,
> >> Deepak
> >
> >
> > https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/19409/1/xyz/openbmc_project/User/Ldap/Config.interface.yaml
> > - the password here is a property, I guess that's the concern. Could
> > the API instead be a method call taking the password - with that it
> > would just be the two processes (and d-bus broker) that would have
> > visibility to this.
> >
> > Regards,
> > Deepak
> >
> >>> On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta
> >>> <ratagupt@linux.vnet.ibm.com> wrote:
> >>>>
> >>>> Hi All,
> >>>>
> >>>> As Discussed in yesterday community call, I did some POC to send the
> >>>> unix FD object over the D-Bus.
> >>>>
> >>>> BackGround: We are exploring the possibilities how to send the secrets
> >>>> from one process to other process,
> >>>>
> >>>> a) If the IPC is D-bus
> >>>>
> >>>> b) Calling process doesn't have the root permission to write the
> >>>> secrets
> >>>> in the configuration file.
> >>>>
> >>>> One of the proposal came, Can the calling process  send the unix fd
> >>>> over
> >>>> the D-Bus instead of sending the actual password
> >>>>
> >>>> and receiving process reads the data from the sent fd.?
> >>>>
> >>>> There was a confusion if some other app can snoop the D-bus message
> >>>> and
> >>>> get the FD and read it.I tried to simulate the same
> >>>>
> >>>> behavior in the POC but not sure whether it is correct or not.
> >>>>
> >>>> This POC has two files which is attached with this mail.
> >>>>
> >>>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
> >>>> unix fd as parameter reads it and send the data back
> >>>>
> >>>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file,
> >>>> then
> >>>> opens the file and send the fd over D-bus.
> >>>>
> >>>>
> >>>> After sending the data over D-bus , I introduced a sleep of 15 sec so
> >>>> that I can try to open the same fd from other
> >>>>
> >>>> process,I open the python shell and try to open the shared FD but
> >>>> couldn't open it.
> >>>>
> >>>> Ratan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-09 19:47 Sending the FD over D-bus Ratan Gupta
  2019-04-10  2:13 ` William Kennington
@ 2019-04-11  7:51 ` vishwa
  2019-04-11  8:11   ` William Kennington
  2019-04-11 17:49   ` Ratan Gupta
  1 sibling, 2 replies; 10+ messages in thread
From: vishwa @ 2019-04-11  7:51 UTC (permalink / raw)
  To: Ratan Gupta, Tanous, Ed, bradleyb, openbmc

Unless I am missing something fundamental, are we saying this ?

Process-1:

fd = open(foo);

send(fd) to another process over D-Bus.

-------------------------------

Process-2:

read the "fd" from D-Bus

read(fd,..)

The process-2 would not even have entries in file desc table to map fd. 
So it would return EBADF. If the read succeeds, then it would be a read 
from a locally opened file that returned the same fd number part of open();

!! Vishwa !!

On 4/10/19 3:47 AM, Ratan Gupta wrote:
> Hi All,
>
> As Discussed in yesterday community call, I did some POC to send the 
> unix FD object over the D-Bus.
>
> BackGround: We are exploring the possibilities how to send the secrets 
> from one process to other process,
>
> a) If the IPC is D-bus
>
> b) Calling process doesn't have the root permission to write the 
> secrets in the configuration file.
>
> One of the proposal came, Can the calling process  send the unix fd 
> over the D-Bus instead of sending the actual password
>
> and receiving process reads the data from the sent fd.?
>
> There was a confusion if some other app can snoop the D-bus message 
> and get the FD and read it.I tried to simulate the same
>
> behavior in the POC but not sure whether it is correct or not.
>
> This POC has two files which is attached with this mail.
>
> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the 
> unix fd as parameter reads it and send the data back
>
> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, 
> then opens the file and send the fd over D-bus.
>
>
> After sending the data over D-bus , I introduced a sleep of 15 sec so 
> that I can try to open the same fd from other
>
> process,I open the python shell and try to open the shared FD but 
> couldn't open it.
>
> Ratan
>
>
>
>
>
>
>
>
>
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-11  7:51 ` vishwa
@ 2019-04-11  8:11   ` William Kennington
  2019-04-11 17:49   ` Ratan Gupta
  1 sibling, 0 replies; 10+ messages in thread
From: William Kennington @ 2019-04-11  8:11 UTC (permalink / raw)
  To: vishwa; +Cc: Ratan Gupta, Tanous, Ed, Brad Bishop, openbmc

Yes, this is what is being said. d-bus supports this and is based on
http://man7.org/linux/man-pages/man3/cmsg.3.html type of fd passing.
It's not actually the same fd number for both processes, but the
backing resource for the fd is the same.

On Thu, Apr 11, 2019 at 12:52 AM vishwa <vishwa@linux.vnet.ibm.com> wrote:
>
> Unless I am missing something fundamental, are we saying this ?
>
> Process-1:
>
> fd = open(foo);
>
> send(fd) to another process over D-Bus.
>
> -------------------------------
>
> Process-2:
>
> read the "fd" from D-Bus
>
> read(fd,..)
>
> The process-2 would not even have entries in file desc table to map fd.
> So it would return EBADF. If the read succeeds, then it would be a read
> from a locally opened file that returned the same fd number part of open();
>
> !! Vishwa !!
>
> On 4/10/19 3:47 AM, Ratan Gupta wrote:
> > Hi All,
> >
> > As Discussed in yesterday community call, I did some POC to send the
> > unix FD object over the D-Bus.
> >
> > BackGround: We are exploring the possibilities how to send the secrets
> > from one process to other process,
> >
> > a) If the IPC is D-bus
> >
> > b) Calling process doesn't have the root permission to write the
> > secrets in the configuration file.
> >
> > One of the proposal came, Can the calling process  send the unix fd
> > over the D-Bus instead of sending the actual password
> >
> > and receiving process reads the data from the sent fd.?
> >
> > There was a confusion if some other app can snoop the D-bus message
> > and get the FD and read it.I tried to simulate the same
> >
> > behavior in the POC but not sure whether it is correct or not.
> >
> > This POC has two files which is attached with this mail.
> >
> > Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
> > unix fd as parameter reads it and send the data back
> >
> > Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file,
> > then opens the file and send the fd over D-bus.
> >
> >
> > After sending the data over D-bus , I introduced a sleep of 15 sec so
> > that I can try to open the same fd from other
> >
> > process,I open the python shell and try to open the shared FD but
> > couldn't open it.
> >
> > Ratan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-11  7:51 ` vishwa
  2019-04-11  8:11   ` William Kennington
@ 2019-04-11 17:49   ` Ratan Gupta
  2019-04-11 20:01     ` Vernon Mauery
  1 sibling, 1 reply; 10+ messages in thread
From: Ratan Gupta @ 2019-04-11 17:49 UTC (permalink / raw)
  To: vishwa, openbmc, openbmc

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]


On 11/04/19 1:21 PM, vishwa wrote:
> Unless I am missing something fundamental, are we saying this ?
>
> Process-1:
>
> fd = open(foo);
>
> send(fd) to another process over D-Bus.
>
> -------------------------------
>
> Process-2:
>
> read the "fd" from D-Bus
>
> read(fd,..)
>
> The process-2 would not even have entries in file desc table to map 
> fd. So it would return EBADF. If the read succeeds, then it would be a 
> read from a locally opened file that returned the same fd number part 
> of open();

Yes, it is true that one process(D-Bus service) can send the FD to other 
process(D-Bus service), How this is achieves internally through D-Bus 
implementation, I have not gone through it, But the spec suggest the same.

|UNIX_FD| 	|h| (104) 	Unsigned 32-bit integer representing an index into 
an out-of-band array of file descriptors, transferred via some 
platform-specific mechanism (mnemonic: h for handle)

Please have a look at the poc also, which I shared. Process 2 doesn't 
have any open file, still it reads the data from the shared fd.

>
> !! Vishwa !!
>
> On 4/10/19 3:47 AM, Ratan Gupta wrote:
>> Hi All,
>>
>> As Discussed in yesterday community call, I did some POC to send the 
>> unix FD object over the D-Bus.
>>
>> BackGround: We are exploring the possibilities how to send the 
>> secrets from one process to other process,
>>
>> a) If the IPC is D-bus
>>
>> b) Calling process doesn't have the root permission to write the 
>> secrets in the configuration file.
>>
>> One of the proposal came, Can the calling process  send the unix fd 
>> over the D-Bus instead of sending the actual password
>>
>> and receiving process reads the data from the sent fd.?
>>
>> There was a confusion if some other app can snoop the D-bus message 
>> and get the FD and read it.I tried to simulate the same
>>
>> behavior in the POC but not sure whether it is correct or not.
>>
>> This POC has two files which is attached with this mail.
>>
>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes 
>> the unix fd as parameter reads it and send the data back
>>
>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file, 
>> then opens the file and send the fd over D-bus.
>>
>>
>> After sending the data over D-bus , I introduced a sleep of 15 sec so 
>> that I can try to open the same fd from other
>>
>> process,I open the python shell and try to open the shared FD but 
>> couldn't open it.
>>
>> Ratan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Ratan

[-- Attachment #2: Type: text/html, Size: 4146 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Sending the FD over D-bus
  2019-04-11 17:49   ` Ratan Gupta
@ 2019-04-11 20:01     ` Vernon Mauery
  0 siblings, 0 replies; 10+ messages in thread
From: Vernon Mauery @ 2019-04-11 20:01 UTC (permalink / raw)
  To: Ratan Gupta; +Cc: vishwa, openbmc

On 11-Apr-2019 11:19 PM, Ratan Gupta wrote:
>
>On 11/04/19 1:21 PM, vishwa wrote:
>>Unless I am missing something fundamental, are we saying this ?
>>
>>Process-1:
>>
>>fd = open(foo);
>>
>>send(fd) to another process over D-Bus.
>>
>>-------------------------------
>>
>>Process-2:
>>
>>read the "fd" from D-Bus
>>
>>read(fd,..)
>>
>>The process-2 would not even have entries in file desc table to map 
>>fd. So it would return EBADF. If the read succeeds, then it would be 
>>a read from a locally opened file that returned the same fd number 
>>part of open();
>
>Yes, it is true that one process(D-Bus service) can send the FD to 
>other process(D-Bus service), How this is achieves internally through 
>D-Bus implementation, I have not gone through it, But the spec suggest 
>the same.

It is not necessarily the same. This is accomplished using the msghdr 
headers in sendmsg (read sendmsg(2) and cmesg(3) and 
https://keithp.com/blogs/fd-passing/ )

>|UNIX_FD| 	|h| (104) 	Unsigned 32-bit integer representing an index 
>into an out-of-band array of file descriptors, transferred via some 
>platform-specific mechanism (mnemonic: h for handle)
>
>Please have a look at the poc also, which I shared. Process 2 doesn't 
>have any open file, still it reads the data from the shared fd.
>
>>
>>!! Vishwa !!
>>
>>On 4/10/19 3:47 AM, Ratan Gupta wrote:
>>>Hi All,
>>>
>>>As Discussed in yesterday community call, I did some POC to send 
>>>the unix FD object over the D-Bus.
>>>
>>>BackGround: We are exploring the possibilities how to send the 
>>>secrets from one process to other process,
>>>
>>>a) If the IPC is D-bus
>>>
>>>b) Calling process doesn't have the root permission to write the 
>>>secrets in the configuration file.
>>>
>>>One of the proposal came, Can the calling process  send the unix 
>>>fd over the D-Bus instead of sending the actual password
>>>
>>>and receiving process reads the data from the sent fd.?
>>>
>>>There was a confusion if some other app can snoop the D-bus 
>>>message and get the FD and read it.I tried to simulate the same
>>>
>>>behavior in the POC but not sure whether it is correct or not.
>>>
>>>This POC has two files which is attached with this mail.
>>>
>>>Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes 
>>>the unix fd as parameter reads it and send the data back
>>>
>>>Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the 
>>>file, then opens the file and send the fd over D-bus.
>>>
>>>
>>>After sending the data over D-bus , I introduced a sleep of 15 sec 
>>>so that I can try to open the same fd from other
>>>
>>>process,I open the python shell and try to open the shared FD but 
>>>couldn't open it.
>>>
>>>Ratan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>Ratan

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-04-11 20:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-09 19:47 Sending the FD over D-bus Ratan Gupta
2019-04-10  2:13 ` William Kennington
2019-04-10  4:53   ` Deepak Kodihalli
2019-04-10  4:58     ` Deepak Kodihalli
2019-04-10  6:16       ` Ratan Gupta
2019-04-10  9:20         ` William Kennington
2019-04-11  7:51 ` vishwa
2019-04-11  8:11   ` William Kennington
2019-04-11 17:49   ` Ratan Gupta
2019-04-11 20:01     ` Vernon Mauery

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.