On Mon, Mar 14, 2016 at 02:35:13PM +0100, Svante Signell wrote:
> On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote:
> > On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote:
> > > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> > > > Why, because it doesn't have a sleep
Svante Signell, on Mon 14 Mar 2016 14:35:13 +0100, wrote:
> On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote:
> > On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote:
> > > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> > > > Why, because it doesn't have a sleep state
On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote:
> On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> > > Why, because it doesn't have a sleep statement?
> >
> > I was referring to strict logic: it's not just beca
Svante Signell, on Mon 14 Mar 2016 14:29:56 +0100, wrote:
> On Mon, 2016-03-14 at 12:20 +0100, Svante Signell wrote:
> > On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:
>
> > > > And with my old implementation it worked perfectly too.
> > >
> > > Because it was synchronous, which was po
On Mon, 2016-03-14 at 12:20 +0100, Svante Signell wrote:
> On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:
> > > And with my old implementation it worked perfectly too.
> >
> > Because it was synchronous, which was posing other problems.
Yet the problem is if the implementation should
On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> > Why, because it doesn't have a sleep statement?
>
> I was referring to strict logic: it's not just because it happens to
Also, using sleep for synchronization is always
Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 14 Mar 2016 09:05:56 +0100, wrote:
> > > On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> > > > Svante Signell, on Sun 13 Mar 2016 14:19:35 +01
On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 14 Mar 2016 09:05:56 +0100, wrote:
> > On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> > > Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> > > > Running the code reveals that the current imple
Svante Signell, on Mon 14 Mar 2016 09:05:56 +0100, wrote:
> On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> > Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> > > Running the code reveals that the current implementation in glibc is
> > > buggy:
> > >
> > > ./scm_rights+cred
On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> > Running the code reveals that the current implementation in glibc is buggy:
> >
> > ./scm_rights+creds_recv
> > Number of SCM_RIGHTS [<=3], SCM_CREDS [<=2]: [1,1]
Hello,
Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> Running the code reveals that the current implementation in glibc is buggy:
>
> ./scm_rights+creds_recv
> Number of SCM_RIGHTS [<=3], SCM_CREDS [<=2]: [1,1]
> Input error: Using defaults:
> NRIGHTS = 1, NCREDS = 1
> scm_rights+c
On Sun, 2015-09-20 at 20:28 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Sun 20 Sep 2015 13:17:36 +0200, a écrit :
> > I'll have a stab at cleaning your patches.
>
> I have pushed the result on the t/sendmsg-SCM_CREDS branch. Note that I
> have refactored the t/sendmsg-SCM_RIGHTS branch, s
Samuel Thibault, le Sun 20 Sep 2015 13:17:36 +0200, a écrit :
> I'll have a stab at cleaning your patches.
I have pushed the result on the t/sendmsg-SCM_CREDS branch. Note that I
have refactored the t/sendmsg-SCM_RIGHTS branch, so make sure to update
your SCM_RIGHTS patch from that branch.
I'll
Samuel Thibault, le Thu 05 Mar 2015 03:23:46 +0100, a écrit :
> Samuel Thibault, le Thu 05 Mar 2015 03:07:18 +0100, a écrit :
> > Was the synchronous/asynchronous issue solved?
>
> I guess not, and I think I know why: in the
> auth_server/user_authenticate loop, the server passes a port back to th
Samuel Thibault, le Thu 05 Mar 2015 03:07:18 +0100, a écrit :
> Was the synchronous/asynchronous issue solved?
I guess not, and I think I know why: in the
auth_server/user_authenticate loop, the server passes a port back to the
user. This is thus a complete rendez-vous: auth_user_authenticate won
Svante Signell, le Sat 21 Feb 2015 16:09:46 +0100, a écrit :
> Most glib2.0 and dbus tests pass (after bootstrapping).
Most, i.e. not all? Are the failing ones related with SCM_CREDS? Was
the synchronous/asynchronous issue solved?
> + /* FIXME: Currently only ONE port is supported, error out i
On Fri, 2013-12-06 at 00:18 +0100, Svante Signell wrote:
> On Thu, 2013-10-24 at 18:24 +0200, Svante Signell wrote:
> > On Thu, 2013-10-24 at 18:15 +0200, Samuel Thibault wrote:
...
> New patches attached, this time using the auth_user_authenticate() and
> auth_server_authenticate() pair to get the
On Fri, 2013-12-06 at 00:18 +0100, Svante Signell wrote:
> On Thu, 2013-10-24 at 18:24 +0200, Svante Signell wrote:
> > On Thu, 2013-10-24 at 18:15 +0200, Samuel Thibault wrote:
...
> With these patches gamin and glib2.0 work
...
> dbus-daemon works, but some of the tests does not, since
> sendmsg(
On Thu, 2013-10-24 at 18:24 +0200, Svante Signell wrote:
> On Thu, 2013-10-24 at 18:15 +0200, Samuel Thibault wrote:
> > Svante Signell, le Thu 24 Oct 2013 18:14:19 +0200, a écrit :
>
> > Sure, but again, what is the relation between that and having both
> > SCM_RIGHT and SCM_CREDS in the same mes
On Thu, 2013-10-24 at 18:15 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 24 Oct 2013 18:14:19 +0200, a écrit :
> Sure, but again, what is the relation between that and having both
> SCM_RIGHT and SCM_CREDS in the same message?
It was a matter of constructing an if-then-else structure, t
Svante Signell, le Thu 24 Oct 2013 18:14:19 +0200, a écrit :
> On Thu, 2013-10-24 at 17:22 +0200, Samuel Thibault wrote:
> > Svante Signell, le Thu 24 Oct 2013 17:04:58 +0200, a écrit :
> > > On Thu, 2013-10-24 at 16:08 +0200, Samuel Thibault wrote:
> > > > Svante Signell, le Thu 24 Oct 2013 15:38:
On Thu, 2013-10-24 at 17:22 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 24 Oct 2013 17:04:58 +0200, a écrit :
> > On Thu, 2013-10-24 at 16:08 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
> >
> > > > > > + goto label;
> > > > >
>
Svante Signell, le Thu 24 Oct 2013 17:04:58 +0200, a écrit :
> On Thu, 2013-10-24 at 16:08 +0200, Samuel Thibault wrote:
> > Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
>
> > > > > + goto label;
> > > >
> > > > Why skipping SCM_RIGHTS support? The message may contain *both*
On Thu, 2013-10-24 at 16:08 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
> > > > + goto label;
> > >
> > > Why skipping SCM_RIGHTS support? The message may contain *both*
> > > SCM_RIGHT and SCM_CREDS, we have to support that. Likewise on the
Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
> > Well, the question is quite simple: what happens when the sender
> > provides faked ports, e.g. pointing to other proc/auth servers? That's
> > where having to explain how the patch is working would possibly even
> > work out the sec
At Thu, 24 Oct 2013 15:38:11 +0200,
Svante Signell wrote:
> > Well, the question is quite simple: what happens when the sender
> > provides faked ports, e.g. pointing to other proc/auth servers? That's
> > where having to explain how the patch is working would possibly even
> > work out the securi
On Thu, 2013-10-24 at 14:34 +0200, Samuel Thibault wrote:
> Svante Signell, le Thu 24 Oct 2013 13:40:02 +0200, a écrit :
> > We are now checking authorization on the receive side.
>
> Could you explain *how* your patch is working? That is again the piece
> of information which is missing in your
Svante Signell, le Thu 24 Oct 2013 13:40:02 +0200, a écrit :
> We are now checking authorization on the receive side.
Could you explain *how* your patch is working? That is again the piece
of information which is missing in your patch submission. Us having
to guess from the source code is not th
Hi,
New patch, now receiver centric, as requested for SCM_CREDS support for
GNU/Hurd: scm_creds_sendmsg.c.diff and scm_cresd_recvmsg.c.
(previous second patch, (updated scm_creds-sendmsg.c_2.diff) for the
-n option, might not be used, in that case the first attached
(scm_creds-sendmsg.c.diff) pa
Svante Signell, le Wed 16 Oct 2013 11:26:29 +0200, a écrit :
> > All of them. Everything that is provided in cmsgcred is supposed to have
> > been checked by the operating system as being correct.
>
> How to handle case where not all ancillary data is sent, e.g. groups
> missing?
Well, you can st
On Wed, 2013-10-16 at 10:46 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 09:50:27 +0200, a écrit :
>
> Also, you need to check that it works when the sender and the receiver
> don't have the same uid/gid/etc., e.g. root sending to a normal user
> (which is one of the most us
Svante Signell, le Wed 16 Oct 2013 09:50:27 +0200, a écrit :
>
> On Wed, 2013-10-16 at 09:24 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> > > What about being paranoid, and do the check on both the transmit _and_
> > > receive side?
> >
> > Ther
On Wed, 2013-10-16 at 09:24 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> > What about being paranoid, and do the check on both the transmit _and_
> > receive side?
>
> There is no need for a check on the transmit side: the sender does know
> for s
Svante Signell, le Wed 16 Oct 2013 07:35:51 +0200, a écrit :
> OK, I'll move the check to recvmsg.c then. No problem:) We can also do a
> full re-authentication at the receive end, should that be added too?
I don't remember what that means, but you might need that.
In any case, you should really
Svante Signell, le Wed 16 Oct 2013 07:44:11 +0200, a écrit :
> What about being paranoid, and do the check on both the transmit _and_
> receive side?
There is no need for a check on the transmit side: the sender does know
for sure what he is.
Samuel
On Wed, 2013-10-16 at 07:35 +0200, Svante Signell wrote:
> On Wed, 2013-10-16 at 00:49 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> > > Because the receiver does not trust the sender.
> >
> > And that is the *whole* point of SCM_CREDS. Otherwise
On Wed, 2013-10-16 at 00:49 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> > Because the receiver does not trust the sender.
>
> And that is the *whole* point of SCM_CREDS. Otherwise the sender could
> simply write a mere struct, without having to g
Samuel Thibault, le Wed 16 Oct 2013 00:48:35 +0200, a écrit :
> Because the receiver does not trust the sender.
And that is the *whole* point of SCM_CREDS. Otherwise the sender could
simply write a mere struct, without having to go through SCM_*.
Samuel
Svante Signell, le Wed 16 Oct 2013 00:46:54 +0200, a écrit :
> On Wed, 2013-10-16 at 00:42 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> > > On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > > > Svante Signell, le Tue 15 Oct 2013 10:33:
On Wed, 2013-10-16 at 00:42 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> > On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > > > + pids = __getpid();
> > > > +
Svante Signell, le Wed 16 Oct 2013 00:40:18 +0200, a écrit :
> On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > > + pids = __getpid();
> > > + euids = __geteuid();
> > > + auids = __getuid();
> > > + egids = __get
On Wed, 2013-10-16 at 00:28 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> > + pids = __getpid();
> > + euids = __geteuid();
> > + auids = __getuid();
> > + egids = __getegid();
> > + agids = __getgid();
>
> Err, which part of the
Svante Signell, le Tue 15 Oct 2013 10:33:12 +0200, a écrit :
> + pids = __getpid();
> + euids = __geteuid();
> + auids = __getuid();
> + egids = __getegid();
> + agids = __getgid();
Err, which part of the protocol which check that these are actually the
proper value?
Updated second patch, reflecting recent changes in the first patch.
On Tue, 2013-10-15 at 10:36 +0200, Svante Signell wrote:
> Hi,
>
> Patch 2(2) on SCM_CREDS support for GNU/Hurd.
>
> This patch is optional. kFreeBSD dos not support this case (but Linux
> is).
>
> This patch implements the las
Hi,
Patch 2(2) on SCM_CREDS support for GNU/Hurd.
This patch is optional. kFreeBSD dos not support this case (but Linux
is).
This patch implements the last cases in the test code sent to the list
in September 2013, options <-n> and <-z> see
http://lists.debian.org/debian-hurd/2013/09/msg00034.ht
Hi,
Patch 1(2) on SCM_CREDS support for GNU/Hurd.
Time to publish the SCM_CREDS proposal to the list. From the patch there
are some FIXMEs that need to be resolved for a final patch to be
created. I've been running two kvm-images with eglibc built with this
patch for a few weeks now, and haven't
46 matches
Mail list logo
