NIS using port silly port numbers?

NIS using port silly port numbers?

[Paul Furness]

Hi. 

I'm trying to build a nice, new NIS server to replace my existing one.
The old one is running redhat 6.2 plus some updates, and since the new
one is running RH7.3 + updates, I though I might as well build from
scratch the NIS and hopefully therefore ensure that it works properly
and is consistent etc etc. 

The trouble I'm having is this: 

I create the various NIS files (passwd, group, aliases, amd.home and so
on) and have no problems with ypinit -m. I can then run the ypserver
fine. I can then run ypbind and it binds to the correct server (in this
case, the same machine). ypcat and ypwhich do the expected things.  

However. 

If I become non-root, either with su - USERNAME or telnet, yp goes
wrong, and I get this: 

[root@Antonia]# su - furnesp 
id: cannot find name for user ID 578 
bash-2.05a$ 

As you can see, it allows me to become the user, but then cannot read
passwd file. I followed this up in the log, and it seems that when I
become the user, all yp request I make are sent to port number 32773.
This is, of course, blocked by ypserv because it's a number greater than
1024.

I proved that this is the problem by changing the ypserv.conf file to
allow connections from any port. After that, everything works fine. But
I don't want to leave that open. 

I then tried binding another machine to the domain and trying the same
thing there. I got an almost identical error, but the port number was
different. This is the error message it put in the syslog on antonia:

Oct  8 16:49:51 Antonia ypserv[2322]: refused connect from
10.10.20.109:32834 to procedure ypproc_match

On the old NIS server, this was not giving a problem. So what's changed
in the new version of ypserv? Why does it now fail where it previsouly
worked fine? Have RedHat broken NIS in RH7.3? Or was it broken before,
and is now working fine?

If it is now working right, I don't understand what use it could be -
you can't possibly share the passwd file so that everyone can log in,
then block access to it whenever a user actually tries to authenticate;
that's just plain silly!

Oh, the yp versions:

old:  
ypbind (ypbind-mt) 1.7 
ypserv - NYS YP Server version 1.3.9 (with securenets)

New:
ypbind (ypbind-mt) 1.10
ypserv (ypserv) 2.2

I'm pretty sure it's something to do with transition from NYS to NIS,
but the docs say it should work the way it's set up now.

Any ideas?

Paul.
-- 
Paul Furness

Systems Manager

2+2=5 for extremely large values of 2.

Re: NIS using port silly port numbers?

[Dr. Michael Weller]

On 8 Oct 2002, Paul Furness wrote:

> However. 
> 
> If I become non-root, either with su - USERNAME or telnet, yp goes
> wrong, and I get this: 
> 
> [root@Antonia]# su - furnesp 
> id: cannot find name for user ID 578 
> bash-2.05a$ 
> 
> As you can see, it allows me to become the user, but then cannot read
> passwd file. I followed this up in the log, and it seems that when I
[...]
> I'm pretty sure it's something to do with transition from NYS to NIS,
> but the docs say it should work the way it's set up now.
> 
> Any ideas?

Well, yes. Although I never compiled NIS myself. But if you want all NIS
requests originate from ports below 1024 they need to run as root and for
non root associated binary has to be setuid root ( chmod u+s on binary
owned by root).

So I'd guess some of the yp utilities have to be setuid root.
Unfortunately I can't tell you which but you should at least keep that in
mind when double checking docs. this is a typical problem when compiling
binaries on your own. the install scripts don't normally setuid binaries
for you (well a careful admin won't really like scripts to do that for
him).

It would also explain what you see: it works for root but not for other
people.

Note that your error clearly states that your connection originates from a
highport. The problem was not it would connect to a highport.
Again, to solve that 'id' in your case must run as root.

Considering that, it seems not to be a very sane approach to me.
I don't know if this NIS suite comes with very secure id, etc
implementations and if one really must run them setuid root.

It might also be the idea of this secure NIS, that only secure
commands (well, considered secure, that is) like su, login and friends can
use NIS (but not id). If that's not acceptable to you, you'l have to
remove this NIS security option.

Anywas, I already said I'm no NIS expert. But I'm sure your current
problem is that id does not run as root, hence simply cannot use a "<1024"
port.

Michael.

--

Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.

Re: NIS using port silly port numbers?

[Robert Wood]

Dr. Michael Weller wrote:
> On 8 Oct 2002, Paul Furness wrote:
> 
> Anywas, I already said I'm no NIS expert. But I'm sure your current
> problem is that id does not run as root, hence simply cannot use a "<1024"
> port.
> 

Is that really the case, surely the individual binaries are not built 
with specific NIS/NIS+/LDAP etc support?... they simiply call a generic 
name-service library which passes the request onto the relevant client 
(NIS in this case).

If this is the case, it's not the "id" binary that should be setuid 
root, as it the client portion of the NIS software that needs to open a 
priviledged port.

Rob

-- 
Robert Wood
rob@rnwood.co.uk
http://www.rnwood.co.uk/