[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] The *auth server* (or, *authentification server*) is a key component managing [[authentication]] in a Hurd system. It is stated by `/hurd/init`. # Documentation [[*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