Re: gcc4/gfortran

[Brian Salter-Duke]

On Thu, 4 Dec 2008 14:35:02 -0500, Gustavo Seabra <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 8:36 PM, Eric Blake wrote:
>> According to Gustavo Seabra on 12/3/2008 7:38 AM:
>>> 1. Is is safe to remove the old gcc (3.*) packages and replace them by
>>> symlinks to the new gcc4 executables?
>>
>> Read the archives.  Dave has mentioned that he is planning on a future
>> packaging of the gcc packages that use the alternatives package, so that
>> the symlink management of the name gcc can be done automatically to point
>> to either gcc-3 or gcc-4.  But at the moment, I'm not sure whether the
>> gcc-4 package requires files provided by the gcc package, in which case
>> blindly deleting all thing gcc 3.* might break gcc-4.
>>
>
> Got it. But I was actually just planning on removing the gcc and g77
> executables, and make those names point to gcc4 executables instead.
>
> It actually has nothing to do with disk space: the whole point is
> that, when compiling a program, I want to make sure it will *not* use
> g77, but gfortran instead. The way it is now, I have to specify
> gfortran-4 as the fortran compiler, say by using
> FC=/usr/bin/gfortran-4, but one can never be sure exactly how a
> specific 'configure' program will find its compilers. So, the removal
> of gcc/g77 executables and replacing by a symlink would remove any
> possibility for confusion.

That could lead to confusion as the arguments for gfortran are not
identical to those for g77. Myself, I want to have both to check that
code compiles OK with both them.

Brian.

>>> 2. In this case, which executables should I point the symlink to? For
>>> instance, if I were to replace g77 by a symlink to gfortran, which of
>>> the 4 gfortran executables should I use:
>>>
>>> $ locate gfortran | grep exe
>>> /bin/gfortran-4.exe
>>> /bin/i686-pc-cygwin-gfortran-4.exe
>>
>> These are identical copies; one is the name preferred when
>> cross-compiling, the other when doing native compiles.
>
> Got it, thanks.
>
>> But why worry
>> about adding symlinks?  Why not just rely on what the package gave you,
>> since it works?  Are you really that low on disk space?  I suppose they
>> could be made hardlinks to one another, if someone were to invest the time
>> into patching setup.exe to attempt to make hardlinks (instead of its
>> current behavior of blindly creating identical copies, even when the tar
>> file specifies hardlinks).
>>
>>> /usr/bin/gfortran-4.exe
>>> /usr/bin/i686-pc-cygwin-gfortran-4.exe
>>
>> These two are identical to the ones above - you need to read the manual,
>> and remind yourself that /bin and /usr/bin are mount points that visit the
>> same directory.  Removing /bin/gfortran-4.exe would simultaneously make
>> /usr/bin/gfortran-4.exe disappear.
>>
>>>
>>> 3. Lastly, just a dumb question: why do we get multiple executables in
>>> the first place? I noticed that g77 also comes in multiple files:
>>> $ locate g77 | grep exe
>>> /bin/g77.exe
>>> /usr/bin/g77.exe
>>>
>>> Is that really necessary?
>>
>> Yes, because that's how the default mount points are set up.
>
> OK, I had missed the point about /bin and /usr/bin actually pointing
> to the same directory. Things are a lot clearer now.
>
> Thanks,


-- 
   Brian Salter-Duke  Melbourne, Australia
 My real address is b_duke(AT)bigpond(DOT)net(DOT)au
Use this for reply or followup.  Registered Linux user 287938.
  Cygwin for Linux on PCs. 


--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Julio Emanuel]

On Fri, Dec 5, 2008 at 2:24 AM, Phil Betts <[EMAIL PROTECTED]> wrote:
>
> Frankly, there are loads of things that you would need to test and
> you can never be sure you've checked all possible mechanisms.  Given
> that the chroot jail is really an open prison under Windows, one has
> to wonder if it's worth the effort, and what you have proved if all
> of your tests have passed.
>

That's a good point. In fact, written that way, it's an universal
point, because you can always think "where are those holes that I
didn't test about"? :)

Now seriously, we have to think where is the responsibility to
"filter" (I think this is the best describing word for the chroot
implementation on cygwin) the non-valid paths under chroot
environment...
Unless there is specific code in sftp/sshd to handle and filter out
the DOSish paths (which I seriuosly doubt, but the maintainer can
correct me), this is already been filtered in the cygwin dll.
If it is so, Corinna, maybe the implementation is in a bit better
shape than you remember? Can you confirm that this is result from
chroot implementation in cygwin dll? (just morbid curiosity, at this
stage :)

> The best you can say is that you are protected against inadvertent
> access and (possibly) someone casually poking around.
>

Well that is always better than to make available the whole file
system in from of their eyes, isn't it?
You all have probably heard/read a lot, "Security by obscurity" is not
nice, very dangerous, and produces a fake sense of security - and all
it's true, in the right scenarios.
However, I can tell you, whithout a trace of doubt, "Security by
obscurity" ALWAYS wins NO security at all, if you know what you're
doing.
For what is worth, my professional field is indeed security, almost
ten years of it.
As for anything done with proper sense of professionalism, this have
to be weightned against your acceptable level of risk.
But for (e.g) casual file-transfer between in-house servers, I would
always recommend this kind of implementation because it is much better
than a whole-open sftp... or (argh) ftp and the like...

> Don't forget that even if you decide SFTP is "secure enough", you
> need to consider the system as a whole.  One of the problems with

Nothing is 100% secure, so the "secure enough" IS the key, and that is
another way to refer to the acceptable level of risk.
So this advice is true anywhere, anytime. But regarding this SFTP
implementation, what I (and TheO too, I suppose) want to know is not
the myriad of ways that security can go wrong; but only if the chroot
filtering (strictly inside of SFTP implementation) is honored.

>From what we've seen so far, it seems that SFTP responds as expected.
That is all that I want to know.
>From this point forward, we must try to close all other access ways
that does not belong to the scenario... but those are not excuses to
not implement the SFTP chroot.

> Windows' security in general is the number of open ports and services
> that are running.  If unauthorized users are able to gain access to
> the system via any other route, then any security SFTP gives you is
> totally illusory.  You would really need an external, aggressive
> firewall to be sure that the only possible external access was via
> SFTP.

... and that is a good advice - even though that could be
insufficient, depending on the projected use of the SFTP, and it's
position in the network architecture, etc. In short, YMMV.

> You can't rely on just disabling services, because I have
> known them to become enabled again after installing updates (thanks
> MS!)
>
> Phil
> --

--
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/

Installed packages info (and backups)

[John Emmas]

Does anyone know where cygwin stores its information about which packages
are currently installed? e.g. is it in the Windows registry?  Is it on the
main cygwin drive or is it on the drive that contains my (local) package
repository?  Or does setup.exe work it all out at run time?

Here's my scenario  I happened to install cygwin on my C: drive.  But my
local download repository is on a different drive (E: drive).  Suppose I've
installed 500 cygwin packages by a certain date and I back up my C: drive.
Sometime later I install 3 further packages, X, Y and Z but something goes
wrong (possibly not even connected with cygwin).  If I delete my C: drive
and restore it from the backup, will cygwin's setup.exe still think that X,
Y and Z are installed or will it (correctly) realise that only the first 500
packages are installed?

John 



--
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/

Re: Installed packages info (and backups)

[Spiro Trikaliotis]

Hello,

* On Fri, Dec 05, 2008 at 11:26:24AM - John Emmas wrote:
> Does anyone know where cygwin stores its information about which packages
> are currently installed?

My completely unauthoritative answer:

/etc/setup

Also look at

/etc/postinstall
and
/etc/preremove

HTH,
Spiro.

-- 
Spiro R. Trikaliotis  http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Corinna Vinschen]

On Dec  5 10:43, Julio Emanuel wrote:
> If it is so, Corinna, maybe the implementation is in a bit better
> shape than you remember? Can you confirm that this is result from
> chroot implementation in cygwin dll? (just morbid curiosity, at this
> stage :)

THis isn't a question of being good or badly implemented, it's the
simple fact that it doesn't (and can't) provide what people think it
does.  Chroot is a bad fake on Cygwin.  Even a super cool implementation
doesn't change that.

>  But regarding this SFTP
> implementation, what I (and TheO too, I suppose) want to know is not
> the myriad of ways that security can go wrong; but only if the chroot
> filtering (strictly inside of SFTP implementation) is honored.

Given that chroot is implemented within Cygwin, SFTP has nothing to do
with it.  However, this is EOD for me.  You have been warned.  Feel
free to use it, but I, for one, wouldn't.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[PPPP]

Larry Hall (Cygwin) wrote:
> 
> 
> Perhaps a better question is why do you think investigating this problem
> would be different with Cygwin than with any other non-Cygwin application?
> If you find there is something Cygwin-specific in this process that's
> confusing you, it might help us understand you better if you reformulated
> the question with your specific issues stated.
> 
> 

That's a good point.  I don't know for sure it's Cygwin.  What I wanted to
do was to use strace on the process and see if I can find out what it's
doing.  When I tried to do that, it would say cannot attach to process.  I
tried using "strace -p" as well as starting the process with strace.  The
problem I had with starting the process with strace is that with the
arguments I'm passing to the process, strace didn't like it.  I tried
putting quotes around the start command as well.  That's where I'm stuck...
-- 
View this message in context: 
http://www.nabble.com/Application-causes-STATUS_ACCESS_VIOLATION-in-Windows-2008-tp20843624p20855414.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[Larry Hall (Cygwin)]

 wrote:


Larry Hall (Cygwin) wrote:


Perhaps a better question is why do you think investigating this problem
would be different with Cygwin than with any other non-Cygwin application?
If you find there is something Cygwin-specific in this process that's
confusing you, it might help us understand you better if you reformulated
the question with your specific issues stated.




That's a good point.  I don't know for sure it's Cygwin.  What I wanted to
do was to use strace on the process and see if I can find out what it's
doing.  When I tried to do that, it would say cannot attach to process.  I
tried using "strace -p" as well as starting the process with strace.  The
problem I had with starting the process with strace is that with the
arguments I'm passing to the process, strace didn't like it.  I tried
putting quotes around the start command as well.  That's where I'm stuck...


So what's the command line you're using?  Does the following work for
you?

  strace -o ls.out ls /usr


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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/

Cygwin/Python question: NumPy

[Gustavo Seabra]

Hi All,

I have installed all the python packages available from setup.exe,
which includes NumPy. However, I am trying to install another program
(BioPython), which depends on numPy being present, but it can't find
it (see below). Am I missing anything here?

Thanks,
Gustavo.

---

$ python setup.py build
running build
running build_py
*** Numerical Python (NumPy) *** is either not installed or out of date.

This package is optional, which means it is only used in a few
specialized modules in Biopython.  You probably don't need this if you
are unsure.  You can ignore this requirement, and install it later if
you see ImportErrors.
You can find Numerical Python (NumPy) at http://numpy.scipy.org/.

Do you want to continue this installation? (Y/n)  n
running build_ext

$

--
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/

Re: Cygwin/Python question: NumPy

[Brian Dessent]

Gustavo Seabra wrote:

> I have installed all the python packages available from setup.exe,
> which includes NumPy. However, I am trying to install another program

Are you sure about that?  There's only Numeric available through setup,
not NumPy.  Maybe you are thinking of Cygwin Ports, which does have a
python-numpy package.  But that's a separate project.

Brian

--
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/

Re: Cygwin/Python question: NumPy

[Gustavo Seabra]

On Fri, Dec 5, 2008 at 12:55 PM, Brian Dessent wrote:
> Gustavo Seabra wrote:
>
>> I have installed all the python packages available from setup.exe,
>> which includes NumPy. However, I am trying to install another program
>
> Are you sure about that?  There's only Numeric available through setup,
> not NumPy.  Maybe you are thinking of Cygwin Ports, which does have a
> python-numpy package.  But that's a separate project.
>
> Brian

Sorry... My bad. You're right, NumPy NumPy is not there.

Thanks,
Gustavo.

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> 
> You also need to try symlinks that point outside the "jail". Try 
> creating them both from the shell and within SFTP.
> 

Just got back from my Christmas shopping and now back to work :)

I don't know how to create a symlink from inside SFTP so I did it only from 
Console. I have created two files; foo and bar. foo is a link to a file outside
the jail /foo (absolute root), while bar is an ordinary file.

sftp> ls -al
drwxr-xr-x2 root root0 Dec  5 15:52 .
drwxr-xr-x3 root root0 Dec  4 16:22 ..
-rw-r--r--1 root root   34 Dec  5 15:52 bar
lrwxrwxrwx1 root root4 Dec  5 15:49 foo
sftp> get foo
Fetching /home/Administrator/foo to foo
Couldn't stat remote file: No such file or directory
sftp> get bar
Fetching /home/Administrator/bar to bar
/home/Administrator/bar   100%   34 0.0KB/s   00:01

As expected user can't gain access outside his jail. But even if it had worked, 
I wouldn't have created a such "facility" purposedly myself.


> 
> Don't forget that even if you decide SFTP is "secure enough", you 
> need to consider the system as a whole.  One of the problems with
> Windows' security in general is the number of open ports and services 
> that are running.  If unauthorized users are able to gain access to 
> the system via any other route, then any security SFTP gives you is 
> totally illusory.  You would really need an external, aggressive 
> firewall to be sure that the only possible external access was via 
> SFTP.  You can't rely on just disabling services, because I have 
> known them to become enabled again after installing updates (thanks 
> MS!)
> 

Yes, I agree totally. We always put publicly accessible systems behind firewall.


  

--
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/

RE: Finally managed to create a jailed SFTP server, but how secure?

[Thrall, Bryan]

TheO wrote on Friday, December 05, 2008 1:01 PM:

>> You also need to try symlinks that point outside the "jail". Try
>> creating them both from the shell and within SFTP.
>> 
> 
> Just got back from my Christmas shopping and now back to work :)
> 
> I don't know how to create a symlink from inside SFTP

What about:

$ sftp localhost
Connecting to localhost...
sftp> symlink 'C:\Windows' bar
sftp> cd bar
sftp> ls *exe
Alcmtr.exeFramePkg.exe  HideWin.exe

IsUninst.exe  MicCal.exeRTHDCPL.exe

RTLCPL.exeRtlUpd.exeSkyTel.exe

SoundMan.exe  alcwzrd.exe   explorer.exe

hh.exeregedit.exe   twunk_16.exe

twunk_32.exe  winhelp.exe   winhlp32.exe


I don't have my sftp chrooted, but I don't know any reason why the above
wouldn't work on a Cygwin chrooted system.
-- 
Bryan Thrall
FlightSafety International
[EMAIL PROTECTED]

--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[PPPP]

Larry Hall (Cygwin) wrote:
> 
>  wrote:
>> 
>> Larry Hall (Cygwin) wrote:
>>>
>>> Perhaps a better question is why do you think investigating this problem
>>> would be different with Cygwin than with any other non-Cygwin
>>> application?
>>> If you find there is something Cygwin-specific in this process that's
>>> confusing you, it might help us understand you better if you
>>> reformulated
>>> the question with your specific issues stated.
>>>
>>>
>> 
>> That's a good point.  I don't know for sure it's Cygwin.  What I wanted
>> to
>> do was to use strace on the process and see if I can find out what it's
>> doing.  When I tried to do that, it would say cannot attach to process. 
>> I
>> tried using "strace -p" as well as starting the process with strace.  The
>> problem I had with starting the process with strace is that with the
>> arguments I'm passing to the process, strace didn't like it.  I tried
>> putting quotes around the start command as well.  That's where I'm
>> stuck...
> 
> So what's the command line you're using?  Does the following work for
> you?
> 
>strace -o ls.out ls /usr
> 
> 

Thanks Larry.  I ran your command and I was able to strace something.  Here
is the output of the strace:

--- Process 1052, exception C005 at 610610C5
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception C005 at 004096B6


Which isn't very useful...how should I tackle this?
-- 
View this message in context: 
http://www.nabble.com/Application-causes-STATUS_ACCESS_VIOLATION-in-Windows-2008-tp20843624p20860739.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[Larry Hall (Cygwin)]

 wrote:



Larry Hall (Cygwin) wrote:





So what's the command line you're using?  Does the following work for
you?

   strace -o ls.out ls /usr




Thanks Larry.  I ran your command and I was able to strace something.  Here
is the output of the strace:

--- Process 1052, exception C005 at 610610C5
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception C005 at 004096B6


Which isn't very useful...how should I tackle this?


I'd recommend building you app as debug and running it through 'gdb'.
That should help narrow this down quite a bit more.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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/

Re: Emacs not working correctly under the new cygwin server.

[BrettN]

I'm having the exact same issue...any solution for this???

Thanks


Bugzilla from [EMAIL PROTECTED] wrote:
> 
> Hello,
> 
> I've have updated my cygwin install and since the installation of the  
> new Xwindows server, emacs doesn't work anymore.
> It starts correctly, but some fonts seems to be missing.
> The menu bar is displayed correctly, but inside the buffer, everything  
> is displayed as small rectangles.
> I think it is a problem related to fonts because when I start under a  
> bash terminal, some warnings are displayed.
> 
> YC
> 
> $ emacs
> Warning: Cannot convert string  
> "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*"
>   to type FontStruct
> Warning: Cannot convert string  
> "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1
> " to type FontStruct
> -- 
> Transmis via le Webmail FreeSurf: http://www.freesurf.fr
> 
> 
> 
> --
> 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/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Emacs-not-working-correctly-under-the-new-cygwin-server.-tp20458028p20860983.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[Larry Hall (Cygwin)]

Larry Hall (Cygwin) wrote:

 wrote:



Larry Hall (Cygwin) wrote:





So what's the command line you're using?  Does the following work for
you?

   strace -o ls.out ls /usr




Thanks Larry.  I ran your command and I was able to strace something.  
Here

is the output of the strace:

--- Process 1052, exception C005 at 610610C5
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception 06BA at 76A8F35F
--- Process 3572, exception C005 at 004096B6


Which isn't very useful...how should I tackle this?


I'd recommend building you app as debug and running it through 'gdb'.

 ^^^
 your

That should help narrow this down quite a bit more.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> What about:
> 
> $ sftp localhost
> Connecting to localhost...
> sftp> symlink 'C:\Windows' bar

sftp> symlink C:\foobar foobar
sftp> symlink C:\windows windows

sftp> ls -al
drwxr-xr-x2 root root0 Dec  5 19:31 .

drwxr-xr-x3 root root0 Dec  4 16:22 ..

-rw-r--r--1 root root   34 Dec  5 15:52 bar

lrwxrwxrwx1 root root4 Dec  5 15:49 foo

lrwxrwxrwx1 root root8 Dec  5 19:30 foobar

lrwxrwxrwx1 root root9 Dec  5 19:31 windows
sftp> get foobar
Fetching /home/Administrator/foobar to foobar
Couldn't stat remote file: No such file or directory
sftp> cd windows
Couldn't canonicalise: No such file or directory

The command symlink worked but the actual access didn't


  

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> What about:
> 
> $ sftp localhost
> Connecting to localhost...
> sftp> symlink 'C:\Windows' bar
> sftp> cd bar

Sorry I missed out the ', here we go again with ' this time:

sftp> symlink 'C:\foobar' foobar
sftp> symlink 'C:\windows' windows
sftp> ls -al
drwxr-xr-x2 root root0 Dec  5 19:37 .
drwxr-xr-x3 root root0 Dec  4 16:22 ..
-rw-r--r--1 root root   34 Dec  5 15:52 bar
lrwxrwxrwx1 root root4 Dec  5 15:49 foo
lrwxrwxrwx1 root root9 Dec  5 19:37 foobar
sftp> get foobar
Fetching /home/Administrator/foobar to foobar
Couldn't stat remote file: No such file or directory
sftp> cd windows
Couldn't canonicalise: No such file or directory


Same result though


  

--
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/

Fw: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> What about:
>
> $ sftp localhost
> Connecting to localhost...
> sftp> symlink 'C:\Windows' bar
> sftp> cd bar

Sorry I missed out the ', here we go again with ' this time:

sftp> symlink 'C:\foobar' foobar
sftp> symlink 'C:\windows' windows
sftp> ls -al
drwxr-xr-x2 rootroot0 Dec  5 19:37 .
drwxr-xr-x3 rootroot0 Dec  4 16:22 ..
-rw-r--r--1 rootroot  34 Dec  5 15:52 bar
lrwxrwxrwx1 rootroot4 Dec  5 15:49 foo
lrwxrwxrwx1 rootroot9 Dec  5 19:37 foobar
sftp> get foobar
Fetching /home/Administrator/foobar to foobar
Couldn't stat remote file: No such file or directory
sftp> cd windows
Couldn't canonicalise: No such file or directory


Same result though


  

--
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/

Re: Application causes STATUS_ACCESS_VIOLATION in Windows 2008

[PPPP]

 wrote:
> 
> 
> Thanks Larry.  I ran your command and I was able to strace something. 
> Here is the output of the strace:
> 
> --- Process 1052, exception C005 at 610610C5
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception 06BA at 76A8F35F
> --- Process 3572, exception C005 at 004096B6
> 
> Which isn't very useful...how should I tackle this?
> 

I got more in the DOS window:

Memory Problem, can't allocate memory
0   0 [main] paAgent.exe 1025 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
0 500 [main] paAgent 1025 handle_exceptions: Dumping stack trace to
paAgent.exe.core
0   0 [main] paAgent.exe 1023 sync_with_child: child 3252(0x178)
died before initialization with status code 0
0 384 [main] paAgent 1023 sync_with_child: *** child state waiting
for longjmp
14873272 14873656 [main] paAgent 1023 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
  595 14874251 [main] paAgent 1023 handle_exceptions: Dumping stack trace to
paAgent.exe.core



-- 
View this message in context: 
http://www.nabble.com/Application-causes-STATUS_ACCESS_VIOLATION-in-Windows-2008-tp20843624p20861151.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> 
> From what we've seen so far, it seems that SFTP responds as expected.
> That is all that I want to know.
> From this point forward, we must try to close all other access ways
> that does not belong to the scenario... but those are not excuses to
> not implement the SFTP chroot.
> 

Actually, my real case is even simpler than this. My SFTP users are all 
"friendly", 
they are not unknown to me. It is a cooperative environment and to be honest, I 
don't believe that they would harm my system by hacking into it.

But I don't want them to poke around and see the content of other directories 
which
do not concern them, read my config files, see who other users are or list the 
content
of my C: drive, ...

Yes so far the set up looks as expected. However, I would have preferred better 
if
/cygdrive was not visible too even if they can't do anything with it. Ideally 
there
should not be anything which could give them any hint on the type of my 
platform.

I don't know who creates /cygdrive here. It is not required in this chroot'ed 
environment. My guess, it is created by sftp-server at start up (regardless 
whether
it runs under chroot'ed environment or not). Maybe someone can confirm this 
better than
me.



One more thing to add.

According to its RFC (4254), once a session is established, SSH allows the 
client to specify
anycommand to execute or any subsystem to be spawned on the server side.

But I think I am safe here too because;

1. I only put sftp subsystem in the sshd_config so any other subsystem request 
will fail.
2. No command can be executed since it requires /bin/bash (or another shell as 
defined by
   /etc/passwd) to be present in the jail.


  

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> 
> THis isn't a question of being good or badly implemented, it's the
> simple fact that it doesn't (and can't) provide what people think it
> does.  Chroot is a bad fake on Cygwin.  Even a super cool implementation
> doesn't change that.
> 

I don't know how chroot is implemented but so far everything looks fine Corinna.
Normal files in C: drive are not visible because they would have to be mapped to
/cygdrive/c/xxx first (and /cygdrive/c doesn't exist).

I think the only possibility too see out of jail is by accessing Windows special
file names like COM1, LPT1 or pipe names. But this is inherent to "Cygwin over 
Windows"
filesystem not just to chroot.

Fortunately I can live without COM1 or LPT1 (I can remove or disable them).


  

--
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/

L.inker errors in compiling l.atest G.T.K.+

[sowiso]

[I apologize for the ugly subject format, but after running 3 times into
the spam script, I was getting tired of it. Sourceware should really fix
its broken detection routines.]

Hi,

I'm simply unable to build latest GTK+ (2.14.5) on cygwin atm.
I have a bit of building experience, though, so it might simply be a
Cygwin-specific thing I don't know about.
(NOTE: This may be a long post.)

First of all, the GTK+ tree seems to have some bugs:

[0] Preamble: -lintl is always linked in TWICE - this is nonsense.
Commenting out LIBS = -lintl in the Makefile(s) did the trick.

[1] BOTH -export-symbols and -export-symbols-regex were specified.
This lead to a fatal error, since these are mutually exclusive an must
not be specified at the very same time.
#Commenting out the line
LIBTOOL_EXPORT_OPTIONS = -export-symbols-regex "^[^_].*"
let me continue without problems.

[2] On Cygwin, WINDRES environment variable in gdk/win32/rc was not
recognized, transforming this line in the Makefile:
$(WINDRES) gdk.rc $@
to
gdk.rc $@

This resulted in lots of ugly errors. When completing the line WINDRES =
/usr/bin/windres in the parent Makefile, everything worked up to ...

[3] ... this point. Lots of coffee breaks later, it breaks off at this
LONG line:

libtool: link: if test "x`/usr/bin/sed 1q ./gdk.def`" = xEXPORTS; then
cp ./gdk.def .libs/cyggdk-win32-2.0-0.dll.def; else echo EXPORTS >
.libs/cyggdk-win32-2.0-0.dll.def; cat ./gdk.def >>
.libs/cyggdk-win32-2.0-0.dll.def; fi
libtool: link:  gcc -shared .libs/cyggdk-win32-2.0-0.dll.def
.libs/gdk.o .libs/gdkapplaunchcontext.o .libs/gdkcairo.o
.libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o
.libs/gdkdisplaymanager.o .libs/gdkdnd.o .libs/gdkdraw.o
.libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o
.libs/gdkimage.o .libs/gdkkeys.o .libs/gdkkeyuni.o .libs/gdkpango.o
.libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o
.libs/gdkpolyreg-generic.o .libs/gdkrectangle.o
.libs/gdkregion-generic.o .libs/gdkrgb.o .libs/gdkscreen.o
.libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o
.libs/gdkwindowimpl.o .libs/gdkenumtypes.o
libs/gdkkeynames.o  -Wl,--whole-archive
win32/.libs/libgdk-win32.a -Wl,--no-whole-archive  -L/usr/lib -limm32 -l
shell32 -lole32 /usr/lib/libcairo.dll.a -lmsimg32 -lgdi32
/usr/lib/libpixman-1.dll.a -lpng12 /usr/lib/libXrender.dll.a
/usr/lib/libX11.dll.a /usr/lib/libxcb-xlib.dll.a /usr/lib/libxcb.dll.a
/usr/lib/libXau.dll.a /usr/lib/libXdmcp.dll.a
/usr/lib/libfontconfig.dll.a /usr/lib/libexpat.dll.a
/usr/lib/libfreetype.dll.a -lz
../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.dll.a /usr/lib/libgio-2.0.dll.a
/usr/lib/libgobject-2.0.dll.a /usr/lib/libgmodule-2.0.dll.a
/usr/lib/libglib-2.0.dll.a -luser32 -lkernel32 /usr/lib/libintl.dll.a
/usr/lib/libiconv.dll.a  -Wl,win32/rc/gdk-win32-res.o -Wl,-luuid   -o
.libs/cyggdk-win32-2.0-0.dll -Wl,--enable-auto-image-base -Xlinker --out
-implib -Xlinker .libs/libgdk-win32-2.0.dll.a

Creating library file: .libs/libgdk-win32-2.0.dll.a

.libs/gdkcolor.o: In function `gdk_color_to_string':
/home/Administrator/build/gtk+-2.14.5/gdk/gdkcolor.c:376: undefined
reference to `_pango_color_to_string'
.libs/gdkcolor.o: In function `gdk_color_parse':
/home/Administrator/build/gtk+-2.14.5/gdk/gdkcolor.c:340: undefined
reference to `_pango_color_parse'

[BIG SNIP - 50 undefined pango_* references later...]

.libs/gdkpango.o: In function `gdk_pango_renderer_draw_glyphs':
/home/Administrator/build/gtk+-2.14.5/gdk/gdkpango.c:251: undefined
reference to `_pango_cairo_show_glyph_string'
win32/.libs/libgdk-win32.a(gdkfont-win32.o): In function
`gdk_font_from_description_for_display':
/home/Administrator/build/gtk+-2.14.5/gdk/win32/gdkfont-win32.c:1246:
undefined reference to `_pango_font_description_get_size'
collect2: ld returned 1 exit status
make[4]: *** [libgdk-win32-2.0.la] Error 1
make[4]: Leaving directory `/home/Administrator/build/gtk+-2.14.5/gdk'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/Administrator/build/gtk+-2.14.5/gdk'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/Administrator/build/gtk+-2.14.5/gdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Administrator/build/gtk+-2.14.5'
make: *** [all] Error 2


I do have a theory, though.
Pango is trunk and has been built without problems, BUT ...
As I could see, although _explicitly_ specifying
--enable-shared --enable-static

the libpango*.dll.a files are still from 2005. But probably the compiler
*does* need this .dll.a badly! Yet I'm unable to build a .dll.a, instead
I get:

Warning: This system can not link to static lib archive
/usr/lib/libpango-w32.1.0.la.
I have the capability to make that library automatically link in where
you link this library.
But I can only do this if you have a shared version of the library,
which you do not appear to have.

Has anyone ever fiddled with this recently?
I'd appreciate any help on this.

Regards
-Andreas


--
Unsubscribe info:  http://cygwin.com/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Roger Wells]

TheO wrote:

From what we've seen so far, it seems that SFTP responds as expected.
That is all that I want to know.
From this point forward, we must try to close all other access ways
that does not belong to the scenario... but those are not excuses to
not implement the SFTP chroot.




Actually, my real case is even simpler than this. My SFTP users are all "friendly", 
they are not unknown to me. It is a cooperative environment and to be honest, I 
don't believe that they would harm my system by hacking into it.


But I don't want them to poke around and see the content of other directories 
which
do not concern them, read my config files, see who other users are or list the 
content
of my C: drive, ...

Yes so far the set up looks as expected. However, I would have preferred better 
if
/cygdrive was not visible too even if they can't do anything with it. Ideally 
there
should not be anything which could give them any hint on the type of my 
platform.

  
if you are concerned about the "cygdrive" text there is a registry entry 
where you can set that to whatever you want including "". That is what I 
do. I would tell you what it is but my windows machine is not here right 
now. Then when you "ls /" you get /c, /d etc instead of /cygdrive/c, 
/cygdrive/d, etc.

cheers,
roger wells
I don't know who creates /cygdrive here. It is not required in this chroot'ed 
environment. My guess, it is created by sftp-server at start up (regardless whether

it runs under chroot'ed environment or not). Maybe someone can confirm this 
better than
me.



One more thing to add.

According to its RFC (4254), once a session is established, SSH allows the 
client to specify
anycommand to execute or any subsystem to be spawned on the server side.

But I think I am safe here too because;

1. I only put sftp subsystem in the sshd_config so any other subsystem request 
will fail.
2. No command can be executed since it requires /bin/bash (or another shell as 
defined by
   /etc/passwd) to be present in the jail.


  


--
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/


  


--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
[EMAIL PROTECTED]


--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> if you are concerned about the "cygdrive" text there is a registry entry 
> where 
> you can set that to whatever you want including "". That is what I do. I 
> would 
> tell you what it is but my windows machine is not here right now. Then when 
> you 
> "ls /" you get /c, /d etc instead of /cygdrive/c, /cygdrive/d, etc.
> cheers,
> roger wells

I found an occurence of cygdrive in my registry:

  HKLM\SOFTWARE\Cygnus Solutions\Cygwin\mount v2\cygdrive prefix

I changed it /foo but it didn't worked, it still showed /cygdrive inside the 
Console
and jailed SFTP :(

I googled it and apparently it used to work but is no longer supported at least 
I'm wrong.



  

--
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/

RE: Finally managed to create a jailed SFTP server, but how secure?

[Thrall, Bryan]

TheO wrote on Friday, December 05, 2008 3:46 PM:

>> if you are concerned about the "cygdrive" text there is a registry
entry
>> where you can set that to whatever you want including "". That is
what I do.
>> I would tell you what it is but my windows machine is not here right
now.
>> Then when you "ls /" you get /c, /d etc instead of /cygdrive/c,
/cygdrive/d,
>> etc. 
>> cheers,
>> roger wells
> 
> I found an occurence of cygdrive in my registry:
> 
>   HKLM\SOFTWARE\Cygnus Solutions\Cygwin\mount v2\cygdrive prefix
> 
> I changed it /foo but it didn't worked, it still showed /cygdrive
inside the
> Console 
> and jailed SFTP :(
> 
> I googled it and apparently it used to work but is no longer supported
at
> least I'm wrong. 

I believe it is still supported for Cygwin 1.5. I think what has
happened is the Cygwin DLL created an actual /cygdrive directory (which
is useful for things like bash completion) in your chroot jail. Now that
you've changed the Cygdrive prefix, delete that directory and all should
be good.

BTW, it is preferable to change the Cygdrive prefix with 'mount -c
' rather than mess around in the registry.

-- 
Bryan Thrall
FlightSafety International
[EMAIL PROTECTED]

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Matthew Woehlke]

Roger Wells wrote:
if you are concerned about the "cygdrive" text there is a registry entry 
where you can set that to whatever you want including "". That is what I 
do. I would tell you what it is but my windows machine is not here right 
now. Then when you "ls /" you get /c, /d etc instead of /cygdrive/c, 
/cygdrive/d, etc.


Don't do that, use 'mount' to change it like you're supposed to. (Check 
the fine manpage for how.)


You may need to restart any Cygwin processes for the change to show up.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
For great justice!! -- Captain (Zero Wing)


--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> 
> I believe it is still supported for Cygwin 1.5. I think what has
> happened is the Cygwin DLL created an actual /cygdrive directory (which
> is useful for things like bash completion) in your chroot jail. Now that
> you've changed the Cygdrive prefix, delete that directory and all should
> be good.
> 
> BTW, it is preferable to change the Cygdrive prefix with 'mount -c
> ' rather than mess around in the registry.
> 

Many thanks. I tried it and it worked. I could see in the Console that it has 
changed to/drive (instead of /cygdrive). 

  # mount
  C:\cygwin\bin on /usr/bin type system (binmode)
  C:\cygwin\lib on /usr/lib type system (binmode)
  C:\cygwin on / type system (binmode)
  c: on /drive/c type system (binmode,noumount)

And I could cd to /drive/c from Console too.

But when I tried to restart sshd, I got this message:

  # net start sshd
  bash: /cygdrive/c/WINDOWS/system32/net: No such file or directory

Do I need to change somewhere else too?



  

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[TheO]

> 
> But when I tried to restart sshd, I got this message:
> 
>   # net start sshd
>   bash: /cygdrive/c/WINDOWS/system32/net: No such file or directory
> 
> Do I need to change somewhere else too?

Ignore my previous message. It worked after I closed the last
Console and open a new one.

Many thanks



  

--
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/

Re: Emacs not working correctly under the new cygwin server.

[Sheldon A. Brown]

Bugzilla from [EMAIL PROTECTED] wrote:
> 
> I've have updated my cygwin install and since the installation of the  
> new Xwindows server, emacs doesn't work anymore.
> 

Cygwin only installs a minimal font set after updating now.  See 

http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-where-are-my-fonts


Sheldon
-- 
View this message in context: 
http://www.nabble.com/Emacs-not-working-correctly-under-the-new-cygwin-server.-tp20458028p20863800.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

Re: L.inker errors in compiling l.atest G.T.K.+

[Christopher Faylor]

On Fri, Dec 05, 2008 at 10:11:30PM +0100, sowiso wrote:
>[I apologize for the ugly subject format, but after running 3 times into
>the spam script, I was getting tired of it. Sourceware should really fix
>its broken detection routines.]

Nothing is broken.  You were being blocked because gtk is discussed in
the cygwin-xfree mailing list.

--
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/

Re: Finally managed to create a jailed SFTP server, but how secure?

[Roger Wells]

Matthew Woehlke wrote:

Roger Wells wrote:
if you are concerned about the "cygdrive" text there is a registry 
entry where you can set that to whatever you want including "". That 
is what I do. I would tell you what it is but my windows machine is 
not here right now. Then when you "ls /" you get /c, /d etc instead 
of /cygdrive/c, /cygdrive/d, etc.


Don't do that, use 'mount' to change it like you're supposed to. 
(Check the fine manpage for how.)


You may need to restart any Cygwin processes for the change to show up.

Actually I knew that.  It was years ago that I modified the registry 
directly.

sorry.
rkw

--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
[EMAIL PROTECTED]


--
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/

Setup.exe: all files in one common directory? (not per-server)

[sowiso]

Hi,

the current setup.exe has a little "issue" which I don't like too much:

whenever you select another mirror, the "release" directory will be
BELOW this mirror address.
Could it also be possible to have the "release" directory used together
with _all_ mirrors?
At the moment, I have to merge directories to have all packages in one
parent directory.
(And I do want all packages in one parent directory! With subdirectories
of course, but _not_ the Austrian mirror in ftpat\release, and the
Swiss mirror in switch.ch\release, but only _one_ "release" directory.)

I'm always using Download only, then install later (middle radio
button). I want it that way, don't ask. :)

-Andreas


--
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/

Re: CYGWIN=ntsec, "cp -a", and NT acls

[Brian Dessent]

Rob Walker wrote:

> # make it read-only the windows way
> attrib +R ${FILE}

Note that the +R attribute (and attributes in general) has nothing to do
with ACLs or security, it's a completely different concept.  FAT for
instance supports R/H/S/A attributes but otherwise has a total lack of
any form of ACLs.

I think introducing the 'R' attribute really muddies this example,
because Cygwin sort-of honors it as if it reflected the contents of the
ACL, when it is a separate bit entirely.  You can see this in your
example by adding some calls to getfacl.  You'll see that attrib +R
didn't change any of the ACLs, but nevertheless Cygwin still reports it
without the +w bit in the ls output as 0555 mode, even though its ACL
still indicates write permission.

> The output of the examination above shows me that "cp -a" doesn't
> preserve Full Control for the owner on the copied file.  Is this the
> expected behavior under ntsec?  If I use CYGWIN=nontsec, Full Control is
> preserved.

Well cp is a POSIX program and it has no idea what Windows style NT ACLs
are.  It preserves the Unix modes of the file, in other words it sees
0555 on the source file and 0555 on the destination file, so it's done
it's job as far as it's concerned.  The problem of course is that there
is not a one to one mapping of Unix modes to NT ACLs, so there is more
than one way to express mode 0555.

With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
fall back to the default Windows way where the ACL is inherited from the
directory, which is the same way that things worked when you used a
Windows program to create the first copy of the file.  So the two files
have identical ACLs not because of anything cp -a did or didn't do, but
because they were essentially both created in the same manner and both
inherited the default ACL of the containing directory.

Also, another thing to note is that Cygwin uses the backup privilege of
Administrator accounts to enable root-like unix semantics.  On a nix
system if you are root you can do anything, regardless of permissions. 
This is not so on Windows.  If you've got a file with mode 555, meaning
there are no +w bits, then normal Windows tools won't be able to write
to it which is why you are getting the error.

> Note the "Access is denied".  This is the issue I'm having.  I need for
> the Windows programs to view the file copy the same way they'd view the
> original file.

To summarize, it seems to me that this is the situation: the source file
has an ACL that indicates writable permission but has the +R attribute
set, which Cygwin reflects as a mode of 0555.  You tell cp to copy the
file and its mode, so it creates a new file and gives it mode 0555 as
well.  This means it creates an ACL that denies write permission,
because hey, user asked for 0555.  Since this is presumably an
administrator account, you can continue to write to the file using
Cygwin tools on account of its emulation of root, but you can't with
native tools because the ACL doesn't allow it.

> This is obviously a contrived example.  I don't need to use "cmd /c
> copy" and "cp" interchangeably, but there are a bunch of native Windows
> tools that have the same behavior as "cmd /c copy".  Cygwin's
> interoperability with these are my problem.

So I guess my question is where is this wacky "set +R attribute" step
coming from?  Or alternatively, why are you surprised that you ask to
create an unwritable file and get something that's not writable?

If you want something that actually copies ACLs, not just replicating
modes, then I guess you want to use getfacl/setfacl, e.g.

$ setfacl -f <(getfacl "${FILE}") "${FILE}_copy"

Brian

--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[Brian Dessent]

sowiso wrote:

> Could it also be possible to have the "release" directory used together
> with _all_ mirrors?

You should be able to just specify as the "Local Package Dir" the parent
dir and it should find and union the contents of all the subdirs.

Brian

--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[sowiso]

- Original Message - 
From: "Brian Dessent" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, December 06, 2008 3:13 AM
Subject: Re: Setup.exe: all files in one common directory? (not
per-server)


> sowiso wrote:
>
> > Could it also be possible to have the "release" directory used
together
> > with _all_ mirrors?
>
> You should be able to just specify as the "Local Package Dir" the
parent
> dir and it should find and union the contents of all the subdirs.

No, unfortunately not.

I do have a unique local package directory, set to F:\CygwinInstall\
Setup automagically will generate

F:\CygwinInstall\ftp.switch.ch...\release
F:\CygwinInstall\ftp.univie...at...\release

and so on. __I cannot do anything about this.__
You see? If I do want to avoid this, I must always use the same mirror.
And what if it's unaccessible due to a server downtime?
Bad luck then I guess :)
Or manual-copying-time again.

If you still don't believe, I'm happy to make a screenshot.

-Andreas


--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[Brian Dessent]

sowiso wrote:

> and so on. __I cannot do anything about this.__
> You see? If I do want to avoid this, I must always use the same mirror.
> And what if it's unaccessible due to a server downtime?

Yes, when downloading it will create the files under the mirror's
filename.  That's by design because different mirrors can have different
views of what the latest packages are (and thus different setup.ini
files and so on.)  What I'm saying is that later on when you do the
"install from local dir" step you should be able to continue to specify
F:\CygwinInstall\ as the local package directory and it should
automatically recursively scan the contents of all the different mirror
dirs found under that directory and offer to install the union of all of
them.

Brian

--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[Christopher Faylor]

On Fri, Dec 05, 2008 at 06:41:21PM -0800, Brian Dessent wrote:
>sowiso wrote:
>>and so on.  __I cannot do anything about this.__ You see?  If I do want
>>to avoid this, I must always use the same mirror.  And what if it's
>>unaccessible due to a server downtime?
>
>Yes, when downloading it will create the files under the mirror's
>filename.  That's by design because different mirrors can have
>different views of what the latest packages are (and thus different
>setup.ini files and so on.) What I'm saying is that later on when you
>do the "install from local dir" step you should be able to continue to
>specify F:\CygwinInstall\ as the local package directory and it should
>automatically recursively scan the contents of all the different mirror
>dirs found under that directory and offer to install the union of all
>of them.

And, there is nothing new happening here.  This has been the way
setup.exe has operated for many years.

cgf

--
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/

Re: CYGWIN=ntsec, "cp -a", and NT acls

[Rob Walker]

Brian Dessent wrote:

Rob Walker wrote:

  

# make it read-only the windows way
attrib +R ${FILE}



Note that the +R attribute (and attributes in general) has nothing to do
with ACLs or security, it's a completely different concept.  FAT for
instance supports R/H/S/A attributes but otherwise has a total lack of
any form of ACLs.

I think introducing the 'R' attribute really muddies this example,
because Cygwin sort-of honors it as if it reflected the contents of the
ACL, when it is a separate bit entirely.  You can see this in your
example by adding some calls to getfacl.  You'll see that attrib +R
didn't change any of the ACLs, but nevertheless Cygwin still reports it
without the +w bit in the ls output as 0555 mode, even though its ACL
still indicates write permission.

  

The output of the examination above shows me that "cp -a" doesn't
preserve Full Control for the owner on the copied file.  Is this the
expected behavior under ntsec?  If I use CYGWIN=nontsec, Full Control is
preserved.



Well cp is a POSIX program and it has no idea what Windows style NT ACLs
are.  It preserves the Unix modes of the file, in other words it sees
0555 on the source file and 0555 on the destination file, so it's done
it's job as far as it's concerned.  The problem of course is that there
is not a one to one mapping of Unix modes to NT ACLs, so there is more
than one way to express mode 0555.

With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
fall back to the default Windows way where the ACL is inherited from the
directory, which is the same way that things worked when you used a
Windows program to create the first copy of the file.  So the two files
have identical ACLs not because of anything cp -a did or didn't do, but
because they were essentially both created in the same manner and both
inherited the default ACL of the containing directory.

Also, another thing to note is that Cygwin uses the backup privilege of
Administrator accounts to enable root-like unix semantics.  On a nix
system if you are root you can do anything, regardless of permissions. 
This is not so on Windows.  If you've got a file with mode 555, meaning

there are no +w bits, then normal Windows tools won't be able to write
to it which is why you are getting the error.

  

Note the "Access is denied".  This is the issue I'm having.  I need for
the Windows programs to view the file copy the same way they'd view the
original file.



To summarize, it seems to me that this is the situation: the source file
has an ACL that indicates writable permission but has the +R attribute
set, which Cygwin reflects as a mode of 0555.  You tell cp to copy the
file and its mode, so it creates a new file and gives it mode 0555 as
well.  This means it creates an ACL that denies write permission,
because hey, user asked for 0555.  Since this is presumably an
administrator account, you can continue to write to the file using
Cygwin tools on account of its emulation of root, but you can't with
native tools because the ACL doesn't allow it.

  

This is obviously a contrived example.  I don't need to use "cmd /c
copy" and "cp" interchangeably, but there are a bunch of native Windows
tools that have the same behavior as "cmd /c copy".  Cygwin's
interoperability with these are my problem.



So I guess my question is where is this wacky "set +R attribute" step
coming from? 


[RGW] I'm simulating the case I actually have.  Our version control tool 
creates files that look this way (Owner Full Control, Read-only 
attribute set).




 Or alternatively, why are you surprised that you ask to
create an unwritable file and get something that's not writable?
  


[RGW] I'm surprised that "cp -a" is unable to preserve the Windows 
attributes of the source file, which can be overwritten by Windows tools.



If you want something that actually copies ACLs, not just replicating
modes, then I guess you want to use getfacl/setfacl, e.g.

$ setfacl -f <(getfacl "${FILE}") "${FILE}_copy"
  


[RGW] Hm, looks simple...  Why isn't this part of "cp -a" ?

-Rob


--
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/

Re: CYGWIN=ntsec, "cp -a", and NT acls

[Rob Walker]

Brian Dessent wrote:

Rob Walker wrote:

  

The output of the examination above shows me that "cp -a" doesn't
preserve Full Control for the owner on the copied file.  Is this the
expected behavior under ntsec?  If I use CYGWIN=nontsec, Full Control is
preserved.



Well cp is a POSIX program and it has no idea what Windows style NT ACLs
are.  It preserves the Unix modes of the file, in other words it sees
0555 on the source file and 0555 on the destination file, so it's done
it's job as far as it's concerned.  The problem of course is that there
is not a one to one mapping of Unix modes to NT ACLs, so there is more
than one way to express mode 0555.

With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
fall back to the default Windows way where the ACL is inherited from the
directory, which is the same way that things worked when you used a
Windows program to create the first copy of the file.  So the two files
have identical ACLs not because of anything cp -a did or didn't do, but
because they were essentially both created in the same manner and both
inherited the default ACL of the containing directory.

Also, another thing to note is that Cygwin uses the backup privilege of
Administrator accounts to enable root-like unix semantics.  On a nix
system if you are root you can do anything, regardless of permissions. 
This is not so on Windows.  If you've got a file with mode 555, meaning

there are no +w bits, then normal Windows tools won't be able to write
to it which is why you are getting the error.
  


[RGW] This differs from my experience.  Many Windows tools are able to 
(built to?) twiddle +R and overwrite.  They do not seem to be able to 
handle when the ACLs deny them permission, though.


-Rob

--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[sowiso]

- Original Message - 
From: "Brian Dessent" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, December 06, 2008 3:41 AM
Subject: Re: Setup.exe: all files in one common directory? (not
per-server)

> Yes, when downloading it will create the files under the mirror's
> filename.  That's by design because different mirrors can have
different
> views of what the latest packages are (and thus different setup.ini
> files and so on.)

Yes, and that's another bad point about it!
Different setup.ini files! What's the idea?

Why not one and the same setup.ini which can be read by _any_ mirror?
That's exactly to prevent the left hand not knowing about what the right
is doing or has done.
Just for sharing "charity" for mirror servers which like to do their
thing this does *not* justify the use of N setup.ini's imho.
(N = number of mirrors visited)

> What I'm saying is that later on when you do the
> "install from local dir" step you should be able to continue to
specify
> F:\CygwinInstall\ as the local package directory and it should
> automatically recursively scan the contents of all the different
mirror
> dirs found under that directory and offer to install the union of all
of
> them.

Nice, nice ... but sometimes I also *do* want to install manually
without setup, e. g. sources.
And always having to use Windows search or *nix find first which mirror
the package has been assigned to this time is not really that "cool".

F:\CygwinInstall\release. That would be the sh*t.. And *all* packages
going in there. And one setup.ini. That's the best solution IMHO.

-Andreas


--
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/

Re: CYGWIN=ntsec, "cp -a", and NT acls

[Brian Dessent]

Rob Walker wrote:

> [RGW] Hm, looks simple...  Why isn't this part of "cp -a" ?

You have to understand the history of things.  In the classic unix
world, a file has an owner, a group, a mode, and several timestamps. 
>From the standpoint of what "cp -a" can manipulate portably, that's
basically it.  All of those things are neatly returned by stat(3) and
are easily settable/copyable across various filesystems.

Extended attributes and/or ACLs are a relatively new introduction --
'new' relative to the fact that traditional unix filesystems are more
than 30 years old.  They are also inherently very filesystem and
operating system-specific: everybody does it slightly differently. 
Check out this overview of the subtle differences of a dozen different
platforms' ACL APIs:
.

It's very hard for a general program like 'cp' to know about all these
various ACL APIs, let alone have any idea how it would go about
translating the semantics of one to another, which would be required for
copying across two different filesystems.  Remember that 'cp' comes from
GNU coreutils which is a set of generic tools that target dozens of
various *nix-ish platforms, whereas the implementations of the getfacl
and setfacl commands come from Cygwin itself which has the specific
knowledge of Windows NT ACLs.

> [RGW] This differs from my experience.  Many Windows tools are able to 
> (built to?) twiddle +R and overwrite.  They do not seem to be able to 
> handle when the ACLs deny them permission, though.

Again, attributes have zero to do with security or permissions.  They
are just a few extra advisory bits that the application (or C runtime)
is free to interpret in any way it wants; they offer nothing in the form
of OS-enforced restrictions.  The Cygwin feature of using the 'backup
privilege' to emulate root semantics is about bypassing ACLs, not
attributes.

Brian

--
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/

Re: Setup.exe: all files in one common directory? (not per-server)

[Brian Dessent]

sowiso wrote:

> Yes, and that's another bad point about it!
> Different setup.ini files! What's the idea?

A single setup.ini file describes a particular view of the state of the
distro at a given point in time for a given site.  Mirrors are
inherently loosely synchronized on the order of hours, not seconds, and
it would be insane to expect any higher level of coherency.  You just
have to accept that it's possible that for example a new package was
just uploaded to the master site and that it might take 3 hours for it
to reach mirror A and 6 hours for it to reach mirror B.  If you hit
mirror A and mirror B during that window there would be a discrepancy as
to which version of that package was current.  Thus, state must be
maintained relative to each mirror, there is no such thing as global
state.

> Why not one and the same setup.ini which can be read by _any_ mirror?

There is exactly one master setup.ini on the sourceware site.  But you
cannot expect dozens of independent mirrors to always update in lock
step.  They will have their local view of what is current.

> That's exactly to prevent the left hand not knowing about what the right
> is doing or has done.

Setup reads all the .ini files in the Local Package Directory and
assembles the package state info from all of them to generate a view of
what the latest available version of each package is.

> Nice, nice ... but sometimes I also *do* want to install manually
> without setup, e. g. sources.
> And always having to use Windows search or *nix find first which mirror
> the package has been assigned to this time is not really that "cool".

Well A) you can install source packages with setup.exe.  And B) if you
want a flat layout then mirror the files yourself using any method you
want.  You can use rsync for example to sync your local site to any of
the rsync sites.  You don't have to use setup.exe at all, and you can
have your precious single setup.ini that way.  (This is what I do
personally.)  Whatever method you use to get the files onto your drive
is your own business, setup doesn't care.  All it needs a dir with one
or more setup.ini files.

Brian

--
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/

Re: CYGWIN=ntsec, "cp -a", and NT acls

[Rob Walker]

Thanks for your patience, Brian.

-Rob

Brian Dessent wrote:

Rob Walker wrote:

  

[RGW] Hm, looks simple...  Why isn't this part of "cp -a" ?



You have to understand the history of things.  In the classic unix
world, a file has an owner, a group, a mode, and several timestamps. 
From the standpoint of what "cp -a" can manipulate portably, that's

basically it.  All of those things are neatly returned by stat(3) and
are easily settable/copyable across various filesystems.

Extended attributes and/or ACLs are a relatively new introduction --
'new' relative to the fact that traditional unix filesystems are more
than 30 years old.  They are also inherently very filesystem and
operating system-specific: everybody does it slightly differently. 
Check out this overview of the subtle differences of a dozen different

platforms' ACL APIs:
.

It's very hard for a general program like 'cp' to know about all these
various ACL APIs, let alone have any idea how it would go about
translating the semantics of one to another, which would be required for
copying across two different filesystems.  Remember that 'cp' comes from
GNU coreutils which is a set of generic tools that target dozens of
various *nix-ish platforms, whereas the implementations of the getfacl
and setfacl commands come from Cygwin itself which has the specific
knowledge of Windows NT ACLs.

  
[RGW] This differs from my experience.  Many Windows tools are able to 
(built to?) twiddle +R and overwrite.  They do not seem to be able to 
handle when the ACLs deny them permission, though.



Again, attributes have zero to do with security or permissions.  They
are just a few extra advisory bits that the application (or C runtime)
is free to interpret in any way it wants; they offer nothing in the form
of OS-enforced restrictions.  The Cygwin feature of using the 'backup
privilege' to emulate root semantics is about bypassing ACLs, not
attributes.

Brian

--
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/

  



--
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/

cygwin-1.7: linking difference

[Marco Atzeri]

Hi All,
following the Corinna request I tried to test the 
building of my packages on cygwin-1.7 and I found this
slight difference when linking

on cygwin 1.5 "-lcruft.dll" is accepted as form 
to link versus cygcruft.dll

while on 1.7 the outcome is:

/bin/ld: cannot find -lcruft.dll

of course if I modified the form "in -lcruft"
than everything is fine.

Is it a intentional change ?

Regards
Marco

PS: My packages need c++ and gfortran so I will wait
Dave before uploading on cygwin-1.7 


  

--
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/