summaryrefslogtreecommitdiff
path: root/hurd/translator/auth.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator/auth.mdwn')
-rw-r--r--hurd/translator/auth.mdwn231
1 files changed, 229 insertions, 2 deletions
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn
index 7fd4832c..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
@@ -8,7 +9,8 @@ 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*).
+The *auth server* (or, *authentification server*) is a key component managing
+[[authentication]] in a Hurd system.
It is stated by `/hurd/init`.
@@ -18,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]]
+
+ <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