This is the mail archive of the 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: Error reports and queries

At 01:01 AM 2/7/2002, Michael Bax wrote:
>I installed OpenSSH (and therefore OpenSSL) under Cygwin.  My shell is tcsh.
>When my shell starts up, it gives an error because the last line of
>/etc/profile.d/openssl.csh has an error in the last line.  This should be
>"endif" not "fi".

Thanks.  This has been reported previously and fixed.  See the email list
archives for details (the response indicating this came within the last
week or two).

>If tcsh is invoked from the command line (for example), the MANPATH variable
>gains a duplicate openssl entry.  This is duplicated again each time tcsh is
>The default configuration for tcsh is quite different to most systems'
>default tcsh configuration: noglob is set, command-line typo-correction is
>enabled, etc.  Any chance that this could be changed to a setup that is more
>typical on Unix systems?
>I am a power user, not an administrator.  But inside my Cygwin shell I can
>read, edit and write arbitrary files in /, /etc, /home/Administrator etc.
>This is true both with and without ntsec.  Is this proper behaviour, to
>follow the NTFS permissions and disregard the Posix permissions?

No, it's not proper behavior and not typical.  If you send the output of
your cygcheck -s -r -v to the list, it may be obvious to someone here why
you have this problem.  I assume you set ntsec prior to starting *any*
Cygwin process?

>It appears that ntsec allows *listing* permissions, but the real permissions
>are unchanged with or without ntsec.  Is this right?

Not with ntsec set, assuming you're on NTFS, no.

>What does ntea actually do?  The guide isn't very clear whether this is a
>good thing, or exactly what it does: if it simply allows tracking chmod
>permissions, how do these interact with the ntsec permissions?

They don't.  Actually, I believe 'ntsec' logic overrides 'ntea' logic.
You can check the code if you're looking for more complete details.
The 'ntea' switch stores permissions in the extended attributes of a
file.  On NTFS partitions, this information is kept in the MFT entry 
for the file, so there is no real space overhead.  On FAT file systems,
the information is stored in one file per partition (even on floppies)
named 'EA DATA. SF'.  This file grows exponentially and cannot be deleted 
by anything other than a CHKDSK.  'ntsec' avoids this issue by using the
NT security model to emulate POSIX permissions.  It fits better with the
Window security model but doesn't support permissions on FAT file systems.
If you're on an NT system, using NTFS, use 'ntsec'.  If you need 
permissions on a local FAT file system under NT, use 'ntea' if you don't
mind the huge file overhead (remember, this will affect floppies too).
Use both if you want 'ntsec' on NTFS and 'ntea' on FAT.  Forget everything
I said if you work on 9x! ;-)

Larry Hall                    
RFK Partners, Inc.            
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX

Unsubscribe info:
Bug reporting:

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