On Sat, 6 Jan 2001, Simon Coulter wrote: >> Œ >Hello Benjamin, > ----CUT HERE---- > >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. TCP/IP has nothing to do with local sockets. The socket API itself should support local, TCP, UDP and other sockets. >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. Never tried, just read about. I went directly to sendmsg() and recvmsg(). >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. It seems logical, but if having *ALLOBJ in one side of the socket poses a security risk then IBM should have discontinued one oft the APIs. It didn't therefore such a threat does not exist OR it's fully integrated with OS/400 (what a value!) >>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. I don't see increased security. If you don't want someone to intercept a descriptor simply deny access to the socket in the IFS. OS/400 has finer control over authority than traditional UNIX. >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. The unix source required minimal changes to compile on the OS/400. It runs, but becouse of the security restrictions it fails. >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. I agree. >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. Okay, but lets take a look at this scenario: A server is listening on a TCP port and on a local socket. The clients (remote or local) send control information to the server. If the server finds a match between a TCP and a local client's control information, then passes the TCP socket descriptor to the local client, and closes the connection. At this point the two clients are connected with a TCP socket, and the server is not connected to the clients. The local client is not a child process, but an arbitrary interactive job. As the server should serve many clients concurrently, setting the user identity of the server to that of the client is complicated, and requires the server having *ALLOBJ. I see 4 other "solutions": [a] Give the local clients *ALLOBJ. As these are mainly interactive jobs, giving *ALLOBJ to every user poses real security risk. Maybe adopted authotity... [b] Setting the client's user identity to that of the server. Requires access to a set of APIs for profile switching and others. Not a nice solution, and makes the application totally OS/400 specific. [c] Redesign the application logic. Lot of work, but this is the cleanest way to go. I have the new design already in my mind. [d] Give up. Bad message to others willing to port applications to the AS/400. Not a real option. >>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. If you revoke *ADD, you won't be able to send messages to that queue. Seems bad design that the same authority is needed to send a message to someone and answer a message for someone. I would prefer not having an email address if everyone could reply to the mails I got. >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. I did it when I first noticed. Too bad that many administrators rely on IBM shipped settings, and I fear that there are more "trapdoors" I'm not aware of. Regards, Benjamin Budai >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.