Re^2: Named Pipe Creation

[Badger BA 64810]

In article <2831 at solo8.cs.vu.nl> maart at cs.vu.nl (Maarten Litmaath) writes:
>bbadger at x102c.harris-atd.com (Badger BA 64810) writes:
>\...  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.
>
>This attitude leads to (deeply buried) race conditions.
>-- 
>"I HATE arbitrary limits, especially when |Maarten Litmaath @ VU Amsterdam:
>   they're small."  (Stephen Savitzky)    |maart at cs.vu.nl, mcvax!botter!maart
You're right, and that was the point of saying ``This assumes...''  I was 
considering umask flipping to cause a sort of critical section, but it only 
applies to signal handling, not independent processes.  Signal handlers can 
don't often open files, and could then do their own save/restore of umask.  

The race condition for the ``chmod'' technique is also probably rare, since 
there's probably no process just waiting to read the named pipe.  You probably
have to write the name to a well-known ``connection'' named pipe, or something.
This provides sufficient synchronization for normal cases.  We're not 
concerned in this case with preventing unauthorized access to the pipe. 
The problem was overly-restrictive permissions due to umask restrictions.
So, I still prefer the chmod solution, since it involves one less system call.
(If you're opening multiple pipes, or have a reason to change umask *perm-
anently*, the umask solution is as good or better.)


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 at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.