[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Luke Kendall]

On 24/10/14 21:37, Corinna Vinschen wrote:
 > On Oct 24 17:35, Luke Kendall wrote:
 >> On 24/10/14 02:43, Corinna Vinschen wrote:
 >>> On Oct 22 20:57, Tom Schutter wrote:
 >>>> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
 >>>>> For your convenience I wrote new documentation.  Since this is a TEST
[snip]
 >>>>>
 >>>>>
 >>>>> 'Logon SIDs: The own[huh?  owner's?  user's?] LogonSid is converted'
 >
 > The logon SID of the current session.  I rephrased this now to:
 >
 > "Logon SIDs: The LogonSid of the current user's session is converted ..."
 >
That's clear.
 >> 'if the AD administrators chose an unreasonable[unreasonably] small'
 >>
 >> 'which keeps an analogue value of the trustPosixOffset'
 >> -->
 >> 'which keeps an analog of the trustPosixOffset'
 >
 > British vs. American English...
Sure, and I thought you'd prefer the American, but I'm happy to see 
British spelling.  But the main point was to drop the word "value".  "A 
is an analog of B", not an analog /value/ of B.
 >
 >
 >> 'how do we uniquely differ[distinguish] between them by name?'
 >>
 >> 'very costly (read: slow) sea[r]ch operations'
 >>
 >> (By the way, if you want to belong to multiple groups, is the only 
way to do
 >> this via an /etc/group file?
 >
 > You mean via the gr_mem field?  That's not evaluated anymore.  Group
 > membership is stored in SAM or AD.
No, I was just wondering: does AD allow you to be in multiple groups? It 
must, I suppose.  (It was an idle question, not really on the subject of 
the documentation.)
 >
 >
 >> Also, it occurs to me that another way to
 >> store the unix home dir, etc., would be a 'partial passwd' file that 
omitted
 >> the fields for the parts supplied easily by AD (SID, GID)?  That's 
just an
 >> idle thought.)
 >
 > But that means you have to read the files again.  Thre's not much of an
 > advantage to having full passwd and group files then for the user, nor
 > for Cygwin itself.  Plus, you have to implement two different reading
 > algos per file type.
True.  Forget it, dumb idea.
 >
 >> 'Cygwin process tree, which[ever?] first process'
 >
 > Hmm.  Sounds bad, right?
Um, awkward and not quite clear, yes.
 > What I'm trying to say is, if the first
 > process of a process tree found cygserver isn't started, it will not try
 > to ask cygserver again, and it will propagate the lack of cygserver to
 > the child processes, so they will neither try to contact cygserver.  If
 > you have a catchy way to phrase this in less words, I'd be quite happy.
 >
 > Btw.
 >
 > In the document I'm talking of the "first process of a Cygwin process
 > tree" throughout.  Is it clear at all what that means?

I think your description is reasonably clear.

 >  For a Cygwin
 > Terminal session that would be the mintty process.  If you have this:
 >
 >   Cygwin process 1 starts Cygwin process 2
 >   Cygwin process 2 starts CMD.EXE
 >   CMD.EXE starts Cygwin process 3
 >   Cygwin process 3 starts Cygwin process 4
 >
 > Then you have two Cygwin process trees with Cygwin process 1 and
 > Cygwin process 3 being the "first processes in a Cygwin process tree".
 >
 > Is there a better way to phrase this in English?  Would it make more
 > sense to use "parent" or "grandparent" for the first process?  Or
 > any other expression?

Hmm.

Well, you open the section by saying:

"The information fetched from file or the Windows account database is 
cached by the process. The cached information is inherited by child 
processes."

What about if you said:

"The information fetched (from file or from the Windows account 
database), is cached by the first process in the process tree. This 
cached information is inherited by every child process."

A little later you say:

"If cygserver is running it will provide passwd and group entry caching 
for all processes in a Cygwin process tree, which first process has been 
started after cygserver."

Maybe:

"If cygserver is running, it will provide passwd and group entry caching 
for all processes in every Cygwin process tree started after cygserver."

But what I hadn't realised until I read your reply, above, was that if 
you're not running cygserver, that if a Cygwin process is started from a 
Windows command in a Cygwin process tree, that new Cygwin process is the 
root of a new Cygwin process tree.

I wonder if the opening sentence should therefore say something like:

"The information fetched from file or the Windows account database is 
cached by the process. The cached information is inherited by child 
/Cygwin/ processes. (A Cygwin process invoked from a Windows command, 
such as CMD.exe, will start a fresh process tree unless /cygserver/ is 
running.)"

BTW, you could say "root of the process tree", but "root" tends to get 
confused with (superuser) root quite easily, so care would be needed.  I 
think "first process" is pretty clear.



 >> 'If both[,] files and db are specified'
 >
 > There is a comma already.  Or am I looking into the wrong line?

Sorry, I was too terse: the comma should be removed:
"If both files and db are specified..."

 >
 >> 'Cygwin will always try the files first, then the db. '
 >> -- is that because the db will always be more trustworthy than the 
files?
 >
 > It's because it doesn't make sense the other way around.  The DBs will
 > always have a valid reply for an existing account, thus there can't be
 > any fallback from db to files.

That's what I was trying to ask.  Thanks.  makes sense.

 >> BTW, the POSIX permission mapping leak used to have a section 
heading; it's
 >> now just unmarked, inside the File Permissions section.  (I'm just 
pointing
 >> that out.)
 >
 > That was deliberate.  I was wondering if the lengthy description of a
 > bordercase in permission handling really deserved its own chapter and
 > came up with a "no".

Perfectly reasonable.

 >> Hope this helps!  You've obviously put a lot of thought and effort 
into all
 >> this: thanks.
 >
 > This really helps a lot, thank you!  I applied a patch in your name,
 > hope that's ok.  I also uploaded this version to
 >
 >   https://cygwin.com/preliminary-ntsec.html
 >
 > If you (or somebody else) have suggestions for the two problems outlined
 > above, I'd be really grateful.
 >
 >
 > Thanks,
 > Corinna

I hope the above is of some help.

Regards,

luke



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