Subject: iruserok() with address-family independence

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 10 Jan 2000 08:14:14 -0800

*BSD and linux (I heard) uses iruserok() and friends as backend
	to ruserok().  the function is publically visible and used from
	rlogind/rshd/whatever, though not well-documented (no manpage on *BSD).
	iruserok has prototype like below and it is IPv4 only:

>int
>iruserok(raddr, superuser, ruser, luser)
>	u_int32_t raddr;			<-- struct in_addr
>	int superuser;
>	const char *ruser, *luser;

	I would like to propose the following variant, which takes sockaddr *,
	for address-family independence:

>int
>iruserok_sa(ra, rlen, superuser, ruser, luser)
>	const void *ra;				<-- const struct sockaddr *
>	int rlen;
>	int superuser;
>	const char *ruser, *luser;

	first argument is typed as const void *, just to avoid dependency
	between unistd.h and sys/socket.h.  it really is (and should be)
	const struct sockaddr *.

	I've been using it on KAME kit and having no problem with it.
	Any opinions on this?  should this be included into future 2292bis
	variant? (i'll write up a section if it should be included).

itojun

--- 2292bis
   14.  Extended interfaces for rresvport, rcmd and rexec ............... 45
       14.1.  rresvport_af .............................................. 45
       14.2.  rcmd_af ................................................... 45
       14.3.  rexec_af .................................................. 46
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Tue, 11 Jan 2000 01:44:30 +0900

> 	I've been using it on KAME kit and having no problem with it.

[Q] What is the meaning of the head letter 'i'?

If it means "IP",  protocol-independent "ruserok_sa" is more 
preferable, isn't it?

-- 
Hideaki YOSHIFUJI <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 11 Jan 2000 01:48:36 +0900

>If it means "IP",  protocol-independent "ruserok_sa" is more 

	I'm not the one who invented iruserok().

	ruserok() itself is completely protocol independent as it takes string
	as hostname part.
	iruserok() is used as backend for ruserok() for IPv4 only.

	I just wanted to make sure iruserok() is usable for IPv4 and IPv6.
	For actual code path please visit the source code.

itojun

---

From: [email-masked]
Date: Tue, 11 Jan 2000 01:38:17 +0900

>To me, using void *, for this reason, sounds like a bizarre hack.
>Wouldn't it be better to add a forward declaration
>  struct sockaddr;
>to unistd.h? There's no reason to include sys/socket.h just for that.

	I'm not sure about the include file dependency issue, and not sure
	if I'm allowed to include forward decl for it.  there should be
	some un*x standards issue.  I need clarification from some POSIX/xopen
	gurus.

itojun

---

From: [email-masked] (Niels M�ller)
Date: 10 Jan 2000 17:36:10 +0100

struct sockaddr;

/Niels

---

From: [email-masked]
Date: Fri, 14 Jan 2000 02:41:04 +0900

>	For actual code path please visit the source code.

	In a second thought ruserok_sa looks okay to me.

	I still think iruserok_sa makes sense, as I'm still not quite sure if
	we ever need to use "ruserok" familiy for non-IP protocols (not IPv4
	nor IPv6).  do we really have such requiement?
	also i see couple of supporting functions, like ivaliduser() and
	icheckhost(), used in iruserok().  this suggest me not to play with
	the function name too much (for historical/least-surprise).

	I need more insight from someone familier with un*x API standards
	(and this is why I posted it here).  To summarize the question:
	- are ruserok() and iruserok() in any of standards?
	  NetBSD manpage says they were from 4.2BSD, nothing more.
	- if we supply address-family neutral version of iruserok (takes
	  sockaddr but I doubt this would be used with non-IP protocol),
	  which is preferable?
		iruserok_sa
		ruserok_sa
	and question to ipngwg:
	- do we need iruserok_sa (or ruserok_sa) in 2292bis?

itojun

---

From: [email-masked]
Date: Thu, 27 Jan 2000 18:39:27 +0900

>	  sockaddr but I doubt this would be used with non-IP protocol),

	there was no voice raised so far.
	just to report that *bsd (well, openbsd and netbsd - and freebsd
	i believe), picked
		iruserok_sa()
	with the following arguments.  function prototype is in unistd.h.
	the reason for first arg being void * (not struct sockaddr *) and
	next being int (not socklen_t) is to avoid dependency between
	sys/socket.h and unistd.h, nothing more.  since we specify
	salen separately, linux/solaris should be happy as well.

>	- do we need iruserok_sa (or ruserok_sa) in 2292bis?

	no need for inclusion.

itojun

int
iruserok_sa(const void *sa, int salen, int superuser, const char *ruser);