From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- hurd/translator/auth.mdwn | 228 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 227 insertions(+), 1 deletion(-) (limited to 'hurd/translator/auth.mdwn') diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 10cfb3aa..68bbce44 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -19,3 +20,228 @@ It is stated by `/hurd/init`. [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk about the details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + +## IRC, freenode, #hurd, 2013-10-31 + +[[!tag open_issue_documentation]] + + is there an in-depth documentation somewhere about the auth server + that explains why there are "reauthenticate" operations everywhere ? + nice, hammar's thesis does it :) + +[[hurd/documentation]], *Generalizing mobility for the Hurd*, Carl Fredrik +Hammar. + + +## IRC, freenode, #hurd, 2013-11-01 + + neal: Thanks, I'm trying to to call auth_server_authenticate + from a libc function, but that fails. That function returns MIG_NO_REPLY. + auth_user_authenticate works OK, but I need the IDs from the + auth_server_authenticate. What to do, implement a new RPC, + modify auth_user_authenticate (probably not) ? + or modify auth_server_authenticate (probably not) + gnu_srs: show the source code you have written. MIG_NO_REPLY is not + expected, unless you called server_authenticate on the wrong port + S_auth_server_authenticate does not have any other exits than + MIG_NO_REPLY (and errors) + auth/auth.c + yes, but it does do auth_server_authenticate_reply, which is what + matters + i.e. what provides the answer + (and the uids etc.) + I don't seem to be able to call that function directly from libc? + eh? You're not supposed to call auth_server_authenticate_reply + yourself, it's auth which is supposed to + precisely to provide the reply to the auth_server_authenticate RPC + again, please show your source code + there must be some mistake + Please show me how to call auth_server_authenticate and that + function returning 0 + there are plenty of examples in the hurd source code + e.g. ext2fs + or libdiskfs, I can't remember where it is exactly inside ext2fs + I've tried all, on avail:( + no* + € git grep auth_server_auth + libiohelp/iouser-reauth.c: err = auth_server_authenticate + (authserver, + was it so hard? + I did, and tried every combination, nothing works! + something has to work, otherwise we'd have no uid authentication + against ext2fs + so there must be a combination you missed + did you understand how the authentication protocol works, for a + start? + otherwise, random code will most probably never work, for sure :) + called from libc? + a libc function? + being from a libc function or from an io_reauthenticate callback + does not really matter + well, random or not, please show me then + it's already there in ext2fs + again, if you don't understand *that* code, no need to try to write + other code, take time to understand what exactly happens in the ext2fs + case + ok, can you tell me how a function only returning MIG_NO_REPLY + can return 0 when called? + by a server or client + maybe one thing you are missing: in the ext2fs case, we have the + sender use io_reauthenticate to provide the receiver (ext2fs) with the + reference port, in the sendmsg/recvmsg, it'll be the message which will + hold the ref port + but otherwise it's all the same + gnu_srs: as I said, by being called on the proper port, + i.e. the auth port, with the ref port provided by the sender + but again, without seeing your code, I can't divine what mistake + you may have done + all I can do is that your code is supposed to really look very much + like the ext2fs case + there is a difference between io_reauthenticarte and + proc_reauthenticate, a subsequent call to auth_user_authenticate returns + 0 in the second case. + i.e. _hurd_setauth in hurd/setauth.c and iohelp_reauth in + libiohelp/iouser-reauth.c + why are you talking about io_reauthenticate an proc_reauthenticate? + again, without seeing your source code, I can't understand what you + are talking about + first: (17:06:23) srs: ok, can you tell me how a function only + returning MIG_NO_REPLY can return 0 when called? + and I can't afford the time to divine + yes, that's iohelp_reauth in libiohelp/iouser-reauth.c + for an example that works + by using the proper ports + if you don't get a reply, it's most probably simply because the + reply goes to the wrong port + again, where/how is the return value communicated by + auth_server_authenticate to the client/caller? + again, it's the auth/auth.c code + which calls auth_server_authenticate_reply + but that function ends with return MIG_NO_REPLY? + yes, because auth_server_authenticate_reply() already did provide + the reply + so the RPC function does not return a reply + since it already explicitly sent one + through auth_server_authenticate_reply + and exits earlier? + it doesn't exit earlier + it first calls auth_serveru_authenticate_reply + and then returns with MIG_NO_REPLY + how the fck should i know that? + by reading MIG documentation? + I believe that _request/_reply mechanism is documented there + MIG magic again:( It strikes back, whatever you do to avoid it + at least I don't think I have divined how it was working, so I must + have read that in some documentation + it's not magic + you just have to read the doc to understand how it works + I've not found any good doc on MIG yet. + depends what you call "good" + MIG is a complex thing, so documentation is complex, yes + that can't really be avoided + mig.pdf + again: how can a function returning MIG_NO_REPLY return 0 when + called (as current implementations show)? + again, by using the proper ports + if not using the proper ports, the reply goes to another port + and thus no reply + and again, without showing the source code, we can't divine how you + didn't use the proper ports + so you mean a reply to a port is the same as the error code + returned? + not always exactly, but basically yes + gnu_srs: *again* , *really*, showing us what you've come up with + would very *most* probably allow us to help you + otherwise it's just guess work and misunderstandings + FYI: there is no libc function calling auth_server_authenticate + directly + sure + that doesn't mean it can't + and here is one code example, not even trying to send+receive, it + is only in recvmsg.c: http://paste.debian.net/63374/ + why is that code doing both auht_user_auth and auth_server_auth ? + it's the sender side which is supposed to call auth_user_auth + and why are you calling proc_reauthenticate, that has nothing to do + with the matter at stake + sorry, you can remove that part, same result + ok but auth_user_authenticate should really go to the sender side + s/should/must + it is supposed to hang until auth_server_authenticate gets called + by the receiver + so putting both on the receiver can not work + at best auth_user_authenticate would hang, waiting for the + auth_server_authenticate which is called just after that... + don't try random code, that can't work + follow what I said + in my mail + I did issue auth_user_authenticate on the send side, and + auth_server_authenticate on the receive side. + that was the path I followed, then when nothing worked,. I tried + the receive side only. + that's why I said don't try random code + it can't work with receive side only + really, go as I said + send / receive + there must be something you made wrong + in the beginning it was not random code;) + but it's not a reason for stabbing in the dark with random code, + that just can't work + then stay with the code at the beginning + and don't start writing random code + that approach can *not* work + still when issuing __proc_reauthenticate followed by + auth_user_authenticate on the send side the port delivered is 0, + i.e. unusable + why calling proc_reauthenticate?? + it has nothing to do with the auth_*_authenticate protocol + really + what made you believe it was part of it? + dunno, if you say so;) + it's not even mentioned in the documentation I referred to in my + mail + again, make sure you actually *understand* the auth_*_authenticate + protocol + I found it in the already implemented code. + and process.defs + for the proc_authenticate protocol, sure + but that has nothing to do with the auth_*_authenticate protocol + well, the hurd documentation does not cover the proc case only + the io case, unfortunately:( Marcus, please write more documentation:-D + it's just the same + exactly the same + ok, now I understand what happend: you followed some code which was + doing the auth protocol with the proc translator, not with the ext2fs + translator + and you had *not* understood what proc_reauthenticate was doing + there + you should have followed some code which was doing the auth + protocol with the ext2fs translator, i.e. through io_reauthenticate, of + course + if you read random code, there's no way you can understand it of + coruse + again, read hurd/setauth.c + it does the reauthentication with ext2fs, through io_reauth to give + the ref prot + s/prot/port + io_reauth has to be replace with a port send over the socket of + course + if that's obvious, don't write code, and ask yourself whether you + have really understood the auth protocol at all + s/that's obvious/that's not obvious/ + understand means being able to match the source code of setauth.c + with the explanation from marcus + I'm learning all the time, in a few years I will be able to + contribute seriously;-) but the MIG stuff, I dunno:( + well, the problem is that it takes us a hell lot of time to explain + you things + just because you don't seem to manage to learn without going + randomly + just reading source code is a random process, unfortunately. + ?! + sure not + if you do it randomly, then it's not wonder you're getting random + don't read it randomly + follow paths + I've never read code randomly, it's a loss of time and a way to + just mix everything together without understanding anything -- cgit v1.2.3