Œ Hello Benjamin, You wrote: >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? The reason for the two APIs is that early AS/400 TCP it didn't support local sockets (Unix domain or AF_UNIX) so although sendmsg() existed it could not be used to pass descriptors. giveDescriptor() and takeDescriptor() were provided (I think at VRM310) to allow descriptors to be passed between jobs. However, they have their own set of annoying behaviour: 1/ takeDescriptor() blocks if there is nothing to receive thus forcing jobs into some sort of synchronization via data queues or similar. 2/ giveDescriptor needs the internal job id of the target job thus requiring additional communication mechanisms (usually a data queue) to pass the job id. The requirement for one side of the connection to have *ALLOBJ is due to the ability to pass descriptors to files for which the non-*ALLOBJ side may not have authority. Note that *ALLOBJ is ONLY required if the source and target jobs run under different user profiles. sendMsg was enhanced (at VRM420 I think) to support passing descriptors and I think the change regarding which job needed *ALLOBJ occurred at this point. I'm guessing here but I think it was probably felt that passing a descriptor from an *ALLOBJ process to a non-*ALLOBJ process posed a security risk especially since descriptors can represent files and therefore a file to which the target job may not be authorized. It seems cleaner to move up the authority hierarchy than down it. I know Unix will let you do this sort of thing (i.e., parent process accepts a descriptor to a file for which it is not authorised from a child that uses set-user-id to run as root) but I don't think that works on the AS/400. An AS/400 program accomplishes similar needs by adopting authority. >For the sendmsg(): it just makes unix to OS/400 portin harder, and doesn't add >value. It doesn't make it harder at all unless you have made design decisions based around platform-specific behaviour and the added value is increased security. You need to do exactly the same things on the AS/400 as you do on Unix to pass descriptors: 1/ create a local socket via socketpair() 2/ spawn a process passing one end of the socket pair (unix may use spawn or more likely fork and exec (or just exec)) 3/ use the connected socket to pass other descriptors --or-- 1/ create local socket() and bind() a path to it 2/ wait for a process to connect() to the local socket 3/ use the connection to pass other descriptors The only difference I can see is that on the AS/400 both processes must have the same user ID (or the descriptor receiver must have *ALLOBJ). Unix appears to allow any process to pass a descriptor to any other process -- but I'm not sure about that. It is actually easier to implement Unix semantics using sendmsg() than it was using givedescriptor(). You should use sendmsg() and recvmsg() rather than givedescriptor() and takedescriptor() unless you need to target a release earlier than VRM420. It would also be better to ensure that the source and target job run under the same user profile rather than requiring *ALLOBJ authority. That's no hardship if one job spawns the others, the spawned jobs will inherit the user profile. >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. Different issue although still security related -- users can only do what they are authorized to do. You need *USE and *ADD authority to the mŒssage queue to reply to message. The default authorities will allow any user to answer messages but changing the QCRTAUT system value and restricting authority to existing message queues will handle that. I will admit that allowing all and sundry to run CHGSHRPOOL or WRKSHRPOOL seems shortsighted but the 'sundry' users ought to have LMTCPB(*YES) specified on their profiles which will stop them running the commands from a command line and you can specifically exclude *PUBLIC from those commands if you desire. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: firstname.lastname@example.org «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» +--- | 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: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.