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