This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin files and devices philosophy


On Sat, 27 Nov 2004, Jason Curl wrote:

> Hello,
>
> I have a general question for the developers of cygwin.
>
> When I open the file "\\.\COM37" this is not opened by cygwin as a
> serial port, but rather as a file. The reasoning (that I'm not
> disputing) is cygwin should have more of a posix/unix flavour. And so
> specific functionality to treat this as a COM port was removed.
>
> So what "should ideally" happen when I open the file?
>
> 1. The file should be opened and no error
>
> 2. The file should be rejected by cygwin, as the paths don't look
> "posix".

It's #1.  Cygwin is not in the business of preventing programmers who
think they know what they're doing from shooting themselves in the foot.
If the programmer tries to open a raw Windows device using POSIX
functionality, it is assumed the programmer intended to do exactly that.
The programmer should know the caveats of doing this.

> If we take 1, it makes the rules simpler. Maybe this was provided
> because we really do want to open this and get a handle. Maybe we want
> to open a network device instead of a hardware device (which has similar
> sematics).
>
> For point 2, this might be considered valid because the path is not
> POSIX and may confuse programs where the file to open is part of a
> command line argument.
>
> In my case, I provide an option for a terminal program what device
> should be used to open the file. I don't want to restrict what devices
> are or are not allowed, except by using function calls to the Posix API
> to determine if the required functionality can be met.

"\\.\COM37" is not POSIX.  Cygwin is POSIX.  You're trying to use POSIX
functions (isatty) on a non-POSIX device -- the result is unspecified
(which means that the above behavior is perfectly valid, as is any other).
If you want to write portable code, why not use the equivalent POSIX
devices?  "/dev/ttyS36" should work, and so should "/dev/com37" (according
to the documentation).

> However, if a user passes '\\.\COM37' it opens, isatty() is successful
> and my software hangs. Should it be up to my program to filter out nasty
> devices, or the underlying API? Needless to say, that this file doesn't
> behave as a tty because the fhandler_disk functions are being used. But
> other functions that I would expect to fail, don't.

Again, the behavior is unspecified.  It's usually bad practice to let
users specify raw devices and use them without any post-processing,
anyway.  Why not let the user select something like "com37", which could
be turned into "\\.\COM37" in Windows-only code, or "/dev/com37" (or even
"/dev/ttyS36") in POSIX code.

> I ask, so that I may understand in what direction cygwin developers
> prefer so I can modify my software in the appropriate way. I'd like it
> not to have any specific knowledge of cygwin, but it will if need be.

It really depends on the goals and the target audience of your program.
If your intended users are expert users who know what they are doing
(always a dangerous assumption), either do the translation from the raw
Windows device syntax to the POSIX device names and use Cygwin, or use
Win32 API calls to process the devices.  If it's a POSIX-compliant
program, which you expect to work on both Unix and Windows (via Cygwin),
you should probably demand the POSIX device names.

It's always safer to present a list of recognized devices in some invented
syntax (using, say, a "-l" command-line flag), and let the user specify
only those devices.  For example, you could use "c1" for "com1", "n1" for
"network device 1" (whatever that means), etc.  The list of devices
doesn't have to be static, but usually is (possibly pruned to only include
the actual devices detected on the system).

> Could something of this nature lead to a security vulnerability in
> cygwin?

This is more likely a security vulnerability in your program.  Cygwin is
only as secure as the underlying platform allows it to be.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]