This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: Missing commands/incorrect behaviour after update
- From: Randall R Schulz <rrschulz at cris dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 12 Nov 2002 10:07:51 -0800
- Subject: RE: Missing commands/incorrect behaviour after update
Michael,
At 09:52 2002-11-12, Eriksson, Michael wrote:
Randall
>
> Perhaps the package search page would benefit from a hint about appending
> ".exe" when looking for command names that are (expected to be) binary
> executables? Of course, doing so would prevent seeing scripts and symlinks.
Thanks for the tip. Due to timeouts I have not been able to check it, but
I will give it a new shot tomorrow.
I would extend the hint to an explanation of the principles behind the
search. (Free-text, database with module content, whatever.)
A patient browser is necessary when accessing this page...
<snip>
> I don't really see why you want a execute bit in your umask. Programs that
> create files typically either use 0666 or 0777 for the new file's mode and
> they do the latter only when they're creating executable files, so putting
> an execute bit in your umask is basically second-guessing the software.
Well, 0666 does not seem like a good idea, since it gives everyone the
right to change the files. Of course the main use of umask is to restrict
access from group and other.
It's a very good idea and has been "the right way" (or, to use a
now-archaic phrase, "The Unix Way (tm)") ever since version 7 Unix when
umask was introduced. The whole point of writing the code to give new files
full access (0666 or 0777) is so that the user is in complete control by
virtue of the "umask."
You do understand that the umask value is "subtracted" (bit-wise) from the
file mode specified by the program creating the new file system entity, right?
As for why I include the 1: It was the official recommendation when I started
university (1994), and I have sofar never had any problems with it.
I will try without 1 for a while.
People make lots of bad recommendations about how to use Unix. This appears
to be one of them. It serves no useful purpose other than to make things
break, as you've seen. The old default of "nontsec" was protecting you from
that failure up until recently when ntsec was switched on by default.
The usual recommendation is 022 or 02, depending on the nature of your user
community and how groups are used in the overall access control strategy.
> As you probably know, directories must bear an applicable execute bit
if their
> contents are to be examined by the "kernel" for opens, creates or cd's,
etc.
> > > As to why the behaviour has changed, ntsec is now on by
> > > default in recent Cygwin DLLs.
> >
> >Speculating that ntsec is means NT security, how do I/can I turn it off?
> >I do almost all security handling through Windows Explorer anyway,
> >since the incompatibilities have caused me to many problems.
>
> Ntsec is documented so speculation is really unnecessary. The switch to
> having it on by default was announced in the release notes for the Cygwin
> package update that included it and because of the change has come up in
> several messages on the Cygwin list since then.
On this point I must admit to never having paid much attention to Cygwin
lists etc. Normally I download a new version every 3-6 months and that's it.
My bad...
That's not an advisable strategy for Cygwin. Occasionally there are upgrade
procedures that if ignored render your system variously crippled. It's rare
and naturally package maintainers try to avoid it, but it's occasionally
necessary.
Frankly, I know of no software for which upgrades can usefully be applied
blindly. Even bug-fix releases can have negative repercussions in some cases.
Michael
Randall Schulz
Mountain View, CA USA
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/