|
Benjamin, Nobody else is answering, so I'll take a stab. I am not sure what UNIX Domain sockets are. But, I have done a lot of work with sockets on the AS/400. All of it using TCP. Also, I am not familiar with sendmsg(). But, give/take_descriptor() I am familiar with. There is no need for *ALLOBJ to do give/take. Give/take is just a way to pass a socket between processes (jobs on the AS/400) and threads. Eg: JobA is doing the listen(). When somebody connects, you do the give_descriptor, send it to another job (worker thread, etc) via some sort of queuing mechanism that then does the take_descriptor, now owns the socket and is able to service the request. Where you might need *ALLOBJ is if you are (or sendmsg is under the covers) using the QSYGETPH and QWTSETP api's which allow you to "assume" the identity of another user. But by default these are shipped *PUBLIC *EXCLUDE. HTH, Bob Crothers Cornerstone Communications http://www.cstoneindy.com -----Original Message----- From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On Behalf Of Benjamin Budai Sent: Friday, January 05, 2001 5:55 AM To: midrange-l@midrange.com Subject: Security? Hi, I am currently writing a program with sockets. Besides TCP it makes use of UNIX domain sockets, for descriptor passing. The API description for sendmsg() states, that the _TARGET_ of the message must be running with the user identity of the sender or have *ALLOBJ. There is another API to do this give_descriptor (I think), which requires the same to stand for the _SOURCE_. What is the rationale behind having two APIs for the same purpose but with opposite security requirements? For the sendmsg(): it just makes unix to OS/400 portin harder, and doesn't add value. The same OS/400 allows ondinary users change the size of shared pools (why?), respond to operator messages (again, why?) and there may be more. Benjamin Budai +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.