On Fri, Mar 7, 2008 at 9:44 PM, RPN01 <[EMAIL PROTECTED]> wrote: > Also: If I violate this using Pipe and the UDP stage, why don't I get a > non-zero return code? The UDP stage quietly accepts records, and the pipe > returns a zero return code, but no data is actually sent. There's no errors
Most certainly CMS Pipelines will slap you on the hand when you try (eg error 1015). But your code may be hiding it. You're right that this has nothing to do with the nature of the UDP network protocol. In general IUCV statements in the CP directory can be used to keep CMS users away from the stack (apart from the old VMCF API). But last time I looked the sample CP directory entries had IUCV ANY and IUCV ALLOW scattered all over the place (a bad example, imho). Since some time, VM TCP/IP by default protects the low port numbers. This is good for the target port of conversations since it prevents the average VM user from acting like a standard service. Though the ports will normally be bound to the standard application, you could think of a denial of service scheme where the application can be tricked into a failure, and the attacker could use the moment until restart to steal the port. At that point, it would also prevent the legitimate server from using it. Basically the only ones that require a low port are the standard services. So when you have put them on the PORT list in VM TCP/IP that is enough to grant access and also to keep others away from that port (DoS). Most applications have two-way traffic, and response goes back to the port number that sent the request. You cannot have different processes use the same port for sending and receiving. So the effect is that conversations that originate from low ports are typically standard applications. The idea is that when it takes root to have that port, the application could be trusted since it was managed by a system admin. Now that each windows user is his own admin on the workstation, this does not make a lot of sense anymore. And finally, there is the issue of re-use of a port number. When someone has used a port, VM TCP/IP will prevent re-use of that port for a short period of time (so that any incoming late traffic is not delivered to the next owner of the port). The example I gave you carefully keeps the port for live while sending UDP datagrams. If you have coded it into an EXEC that establishes a new conversation for each message or each set of messages, you will find VM TCP/IP reject that connection (unless you have reuseaddr). And when you try this trick without specifying the source port number, the stack will have all ports in "don't use for a while" status and runs out of resources. The TCP/IP support in CMS Pipelines requires some delicate plumbing. You really can't get it straight with a crow bar. You want the pipeline segment with the UDP stage to run permanently. You can use a REXX stage to gets the records out of a spool file or whatever, as long is you don't make the UDP stage part of the sipping pipeline. But that's probably something for CMSPIP-L instead. IIRC you can make syslogd accept traffic from other ports than 514. Unless you can fully trust everyone on VM and Linux, you may at least want to define that port in VM TCP/IP and syslogd. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
