On Friday April 20, [email protected] wrote:
> On Friday 20 April 2007 05:04, Neil Brown wrote:
> > One uses 'getpwnam("rpc")' to find a uid to 'setuid' to.
> > This could be a problem is NIS is in use and 'rpc' isn't in
> > /etc/passwd - portmap would be need to find the NIS server to check
> > for 'rpc' before portmap could start.
> > Maybe we should make the uid a compile-time option?
>
> I'd rather make it a command line option. Maximum freedom for users
> to shoot themselves in the foot :-)
Hmmm...
>
> > The other uses gethostbyname to allow tcpwrappers to provide host-name
> > based access control. This is similarly a potential ground for
> > deadlocks, and the man page from Debian explicitly says that isn't
> > supported so presumably a Debian maintainer has thought about it.
>
> I agree that this is probably not a very useful patch. But I think
> the potential for deadlock is actually rather small. For one,
> if you're on a NIS client, I'm not sure the local portmapper is
> involved very much at all. For a NIS lookup that starts with a
> clean state, you need to get the binding information, which
> nowadays is just being read from /var/lib/yp/binding or some
> such. The NIS call itself is being placed to the server, and
> doesn't involve local portmap either. You could possibly
> get yourself into trouble if you have a machine acting as a NIS
> server and client at the same time... but that's really kinky
> stuff.
I guess. It would be really nice if we could delay doing the hostname
lookup until we find a hostname present in hosts.{allow,deny}. That
would make it run-time configurable. I don't think we can do that
though.
>
> > Firstly, registrations made with a privileged port are flagged as
> > such, and can only be deregistered with a request from a privileged
> > port. That makes it safe for statd/mountd etc to listen on
> > unprivileged ports.
>
> That's nice! However, beware you have to patch rpcinfo so that
> rpcinfo -u does a bindresvport when run as root. And *that*
> change needs to go into all distros, or you need to get it past
> Uli "hell will freeze over first" Drepper.
No change needed. The rpc library already does bindresvport when
creating a client.
>
> > Partly to address this, and partly because I think it is a good idea,
> > portmap now keeps a copy of it's mapping table in
> > /var/run/portmap_mapping (even when it chroots elsewhere) and will
> > reload it on restart. So pmap_dump/pmap_set is no longer needed.
>
> I did this quite a while ago when working at Caldera, and there's
> one gotcha I remember quite vividly - you need to reliably find out
> whether you're booting (wipe all registrations), or whether the user
> is just executing "portmap stop; do_silly_stuff; portmap start". Users
> will not accept that "portmap restart" preserves registrations while
> the above sequence of commands doesn't. So you need some
> init script magic to wipe the file when booting. And once you
> solved that, probably some smart person will complain that this
> doesn't work when he starts portmap in initrd :-)
My understanding is that /var/run is cleared early at bood. So the
idea was that the choice of path name made all that work
automatically.
And portmap in initrd? Just Say No. :-)
Thanks for the comments.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday 20 April 2007 10:02, Neil Brown wrote:
> I guess. It would be really nice if we could delay doing the hostname
> lookup until we find a hostname present in hosts.{allow,deny}. That
> would make it run-time configurable. I don't think we can do that
> though.
No, that's not the way tcp_wrappers works. It needs to do the
reverse lookup first.
> > That's nice! However, beware you have to patch rpcinfo so that
> > rpcinfo -u does a bindresvport when run as root. And *that*
> > change needs to go into all distros, or you need to get it past
> > Uli "hell will freeze over first" Drepper.
>
> No change needed. The rpc library already does bindresvport when
> creating a client.
Ah. I was under the impression the automatic bindresvport call
had been removed at some point in time. But looking at the
glibc cvs it seems it's still there.
> My understanding is that /var/run is cleared early at bood. So the
> idea was that the choice of path name made all that work
> automatically.
Well, if you want portmap to chroot, then it either has to keep
a file descriptor open for its map file (which would be at odds
with chrooting, because you do that to completely contain
the process); or you would have to put the map file somewhere
under your chroot tree and have to take care of cleaning it
up on boot in a different way.
> And portmap in initrd? Just Say No. :-)
People have tried to do that, unfortunately.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs