To: Richard Weinberger <richard@nod.at>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>,
        "Theodore Ts'o" <tytso@mit.edu>, Harald Hoyer <harald@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
References: <21824.5086.446831.189915@quad.stoffel.home>
 <5540D2F9.2010704@redhat.com>
 <CAFLxGvzz3ac19J=dC_gWrrY=BG4h-LO+uRn2rOr1eWyVnk3vzg@mail.gmail.com>
 <5540DEEB.2060405@redhat.com> <5540E0C7.3050106@nod.at>
 <5540E432.9020606@redhat.com> <5540E4D9.6000007@nod.at>
 <5540E684.4070606@redhat.com> <5540E821.8050204@nod.at>
 <5540F081.9090005@redhat.com> <20150429150341.GA12374@thunk.org>
 <5540F6E3.8000706@gmail.com> <871tj2ouk2.fsf%l.stelmach@samsung.com>
 <5541F209.8070302@nod.at> <87wq0tor57.fsf%l.stelmach@samsung.com>
 <55420685.8080607@nod.at> <87oam5olpu.fsf%l.stelmach@samsung.com>
 <55421EBB.2010500@nod.at>
From: =?utf-8?Q?=C5=81ukasz_Stelmach?= <l.stelmach@samsung.com>
Date: Thu, 30 Apr 2015 14:40:35 +0200
In-reply-to: <55421EBB.2010500@nod.at>
Message-id: <87k2wtokl8.fsf%l.stelmach@samsung.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-version: 1.0
Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256;
 protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2673
Lines: 66

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:16 schrieb =C5=81ukasz Stelmach:
>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 12:19 schrieb =C5=81ukasz Stelmach:
>>>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>>>>> Am 30.04.2015 um 11:05 schrieb =C5=81ukasz Stelmach:
>>>>>> Regardless, of initrd issues I feel there is a need of a local IPC
>>>>>> that is more capable than UDS.=20
[...]
>>>> For example, a service can't aquire credentials of a client process th=
at
>>>> actually sent a request (it can, but it can't trust them). The service
>>>> can't be protected by LSM on a bus that is driven by dbus-daemon. Yes,
>>>> dbus-daemon, can check client's and srevice's labels and enforce a
>>>> policy but it is going to be the daemon and not the LSM code in the
>>>> kernel.
>>>
>>> That's why I said we can think of new kernel features if they are
>>> needed.  But they current sink or swim approach of kdbus folks is also
>>> not the solution.  As I said, if dbus-daemon utilizes the kernel
>>> interface as much as possible we can think of new features.
>>=20
>> What kernel interfaces do you suggest to use to solve the issues
>> I mentioned in the second paragraph: race conditions, LSM support (for
>> example)?
>
> The question is whether it makes sense to collect this kind of meta data.
> I really like Andy and Alan's idea improve AF_UNIX or revive AF_BUS.

Race conditions have nothing to do with metadata. Neither has LSM
support.

AF_UNIX with multicast support wouldn't be AF_UNIX anymore.

AF_BUS? I haven't followed the discussion back then. Why do you think it
is better than kdbus?

=2D-=20
=C5=81ukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVQiLEAAoJELCuHpyYpYAQqXAH/iimRMUnp/U3yG5CSxhYmjdG
bknTErafPjsWalO7JgNzEA/emhky98h5acWwgcacztP2BXs/hOkdIglqtNk7i+yc
kaFBIlYRJmp6nEcbrUCEf5gbmaqdOyTQ41em5Bxmoa9zEK09OJPyT6RwxX8E/d3x
u/AuPT1t5g+WzBdCq+qJTF+PqTD4SbSnGJu/Ug2MfsP8IhTztFZ2ak/aDUnRyG7p
PH2vlzT0CoHRLk9y2AD097gBF6FQj1K1K4O956yBMEGaR+PI4clXGpoL7OWw8kJu
Azm30XV+iKLaKSTSNjRTC+GrfHl2W5+ZG7aqWfqYngu5ZdO4/40fdwia2PVyzJU=
=UWGu
-----END PGP SIGNATURE-----
--=-=-=--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/