Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcsvax!trantor.harris-atd.com!x102c!bbadger From: bbadger@x102c.harris-atd.com (Badger BA 64810) Newsgroups: comp.unix.questions Subject: Re: Named Pipe Creation Summary: Changing umask is overkill, try chmod Message-ID: <2286@trantor.harris-atd.com> Date: 5 Jul 89 13:58:00 GMT References: <163@cerc.wvu.wvnet.edu.edu> <653@kl-cs.UUCP> Sender: news@trantor.harris-atd.com Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810) Organization: Harris GISD, Melbourne, FL Lines: 28 In article <653@kl-cs.UUCP> pc@cs.keele.ac.uk (Phil Cornes) writes: >From article <163@cerc.wvu.wvnet.edu.edu>, by drs@cerc.wvu.wvnet.edu (Darrell Schiebel): >> I am attempting to create a named pipe which several different users >> can read from and write to, but ...... >> the system creates a pipe with owner r/w, group r, and world r. The >> protection I was expecting is owner r/w , group r/w, wnd world r/w. >The simplest explanation for this is that somewhere in your login sequence >the command: > umask 022 >gets executed. What umask(1) does is ... >What you must do is to issue a new umask(1) command (so that the group and >world write permission bits are not reset) before you run your program, or >issue a umask(2) system call from within your program to achieve the same >effect. Sure, this does the job, but it's overkill. You don't necessarily want umask changed, because there are other files to open, etc. Easier than saving and restoring the umask is simply running ``chmod(pipe_name,mode_bits)'' after creating the named pipe. This assumes that the receiver is synchronized so as to not attempt and fail for the few ms between creation and mode setting. Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.