[comp.unix.questions] Named Pipe Creation

drs@cerc.wvu.wvnet.edu (Darrell Schiebel) (06/30/89)

I am attempting to create a named pipe which several different users
can read from and write to, but when I create the pipe with:

      if (mknod(destination_path,S_IFIFO | 0666, 0) == -1)
        if (errno != EEXIST)
          return(-1);
        else errno = 0;

      sock = open(destination_path,O_RDWR);

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.


Any Suggestions ?

Thank You, 
Darrell Schiebel


-------------------------------------------------------------------------
Darrell Schiebel                  _        _   _   __            __
drs@cerc.wvu.wvnet.edu           | \  /\  |_) |_) |_  |   |     (_ 
Concurrent Engineering Center    |_/ /--\ | \ | \ |__ |__ |__   __) ::
West Virginia University        
-------------------------------------------------------------------------

bill@twwells.com (T. William Wells) (07/02/89)

In article <163@cerc.wvu.wvnet.edu.edu> drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes:
: I am attempting to create a named pipe which several different users
: can read from and write to, but when I create the pipe with:
:
:       if (mknod(destination_path,S_IFIFO | 0666, 0) == -1)
:         if (errno != EEXIST)
:           return(-1);
:         else errno = 0;
:
:       sock = open(destination_path,O_RDWR);
:
: 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.

Surround your code with something like:

	savemask = umask(0);
	...
	(void)umask(savemask);

after, RTFM'ing.

BTW, it looks like you are trying to be clever with errno. Don't. The
only thing you are guaranteed by the documentation is that it is set
properly after a system call returns an error. For all you know, errno
could be set to a random value on success.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

amitc@cbnewsl.ATT.COM (amit.chatterjee) (07/02/89)

In article <163@cerc.wvu.wvnet.edu.edu> drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes:
>I am attempting to create a named pipe which several different users
>can read from and write to, but when I create the pipe with:
>
>      if (mknod(destination_path,S_IFIFO | 0666, 0) == -1)
>......
>
>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.
>

Looks like your umask is set to 022. I believe that regardless of what
you specify as the permission string in your system call, umask takes 
effect.

-Amit


=======================================================================
	Amit Chatterjee			(201) 271-1130
	AT&T CSIL			{major gateway}!tarpon!amit
	Somerset, NJ			amit@tarpon.att.com
=======================================================================

gwyn@smoke.BRL.MIL (Doug Gwyn) (07/02/89)

In article <163@cerc.wvu.wvnet.edu.edu> drs@cerc.wvu.wvnet.edu (Darrell Schiebel) writes:
>Any Suggestions ?

yeah -- set the umask to 0 first.

pc@cs.keele.ac.uk (Phil Cornes) (07/03/89)

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 to specify a pattern of permission bits
that will definitely be reset to 0 whenever a file is created whatever file
permission bits are given in the system call that creates the file.

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.


Phil Cornes          I just called to say .....
-----------*
                     JANET: cdtpc@uk.ac.stafpol.cr83
                     Phone: +44 (0)785 53511 x6058
                     Smail: Staffordshire Polytechnic, Computing Department
                            Blackheath Lane, STAFFORD, ST18 0AD, ENGLAND.

bbadger@x102c.harris-atd.com (Badger BA 64810) (07/05/89)

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.