Deprecating ntea

[Larry Hall (Cygwin Developers)]

Igor Peshansky wrote:
> On Tue, 27 Feb 2007, Corinna Vinschen wrote:
> 
>> As the subject says, I'm all for deprecating the ntea setting.
>>
>> The reason is that it's just an ugly fake.  It's not at all necessary
>> and I even consider it as dangerous, because it pretends a security
>> (permission bits) which doesn't exist.
>>
>> Does anybody have a good argument to keep this cruft against all reason?
> 
> The ntea permission bit support isn't there to fool (most) users, it's
> there to fool (arguably broken) applications that assume they are on a
> secure system and check the permissions.  IIRC, Linux does not support
> permission setting on FAT filesystems, so no sensitive data can reside on
> them.  The answer for Unix is WDDTT.  The answer for Windows is more
> complex, as many people may not have a choice.  That's where ntea comes
> in.
> 
> I'm not arguing for keeping ntea, but I am arguing for having *some*
> mechanism to help users run Unix applications on filesystems without
> security support (how many people still use rsh?).  As I see it, ntea as
> it stands now is broken anyway (it doesn't work on FAT32).  However, does
> it really slow down the common path (i.e., NTFS)?  If all ntea support
> kicks in after the FS is determined to be FAT, then it may be more a
> matter of refactoring the code to make it simpler, rather than
> performance.  However, simpler code is good, so that in itself may be a
> good reason to remove ntea.
> 
> Right now Cygwin doesn't have a concept of "filesystem drivers" (well,
> there's the fhandler* interface, but it doesn't discriminate between NTFS,
> FAT, FAT32, SAMBA, etc).  One idea may be to allow pluggable drivers for
> various filesystems (with a default fallback for unrecognized ones), and
> move all the ntea code into the FAT "driver".  Then people who are
> interested in running on FAT can provide patches to support ntea if they
> so choose (perhaps even outside of the main "cygwin" package, as a
> separate auto-loaded DLL).  Yes, I know, SHTDI.
> 
> In short, if the main list does not complain loudly, ntea is a goner.  But
> if they do, perhaps soliciting help in getting the above refactoring done
> is the way to go.
> 	Igor


There are definitely better ways for ntea to be managed in the code if it's
going to be kept.  I would agree that if we're going to keep it, we should
be thinking about some kind of restructuring like this if for no other
reason than there will come a day where it is of absolutely no value.  So it
would make removing it simpler. ;-)

I'm wondering if there's really allot of call for it though.  Either
everybody that needs it has somehow miraculously found it (through the
FAQ or docs) or nobody is using it.  The former possibility assumes people
read the docs, which definitely doesn't fit the majority profile.  The
latter implies ntea isn't needed.

I can't imagine that there are many NT4 or better machines out there that
rely on FAT (not FAT32) solely.  The last W2K machine I bought 6+ years
ago offered the option to come preinstalled as FAT but was actually FAT32.
I don't know of anyone pre-installing XP on a machine who is offering FAT.
In my opinion, people using FAT on any sizable (i.e. usable) partition with
at least W2K or XP are actually using FAT32.  Unless there's some trick out
there to enable support for ntea on FAT32, I think it's fair to say that
ntea has already been killed by MS.

To me it seems ntea has enough limited applications that it is effectively
unusable.  But I agree with Chris that this needs to be announced on the
main list before killing it off for 1.7.

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