* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).