More about permissions

More about permissions

[Eliot Moss]

Dear Cygwin community --

Along with some others, I've been struggling a little to accommodate
the changes to permissions handling that came lately.  I think I about
have it figured out to work mostly Unix-like within my cygwin tree,
but have one remaining thing I am wondering about, even though I have
been through the ntsec document more than once.  (I think everyone
will admit that this is complicated :-) ...)

- I have created a new group, that I call Cygwin, to be the typical
   group of cygwin-related files, so that I can control group permissions
   appropriately. I am a member of that group.

- I have found that if a directory is chmod to 2755 (2000 == set gid)
   and the directory's group is Cygwin, then cygwin-created files in
   the directory get group Cygwin.  (This was not necessarily happening
   before.)  To get this to happen, I had to list the sid of the Cygwin
   group as my group in my line of the /etc/passwd file.  Otherwise the
   group would be me, which does not seem to allow the same differentiation
   of user versus group permissions.

- I could not find an explanation of the 'mask' list by getfacl.  Near
   as I can tell it is not really settable, although setfacl does not
   complain, and it is the OR of the permissions of the various groups.

Now, to what I would like to do.  Ideally I want SYSTEM to have rwx
access to everything.  Seems a generally good idea on Windows, and at
least r permission on files and rx on directories is needed for my
backup program to access things.

But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls
always lists rwx for the group part of any such file, and chmod, if
applied, affects SYSTEM's access bits.  What I'd like is for SYSTEM's
role here to be hidden.  If there are any files where I want to restrict
SYSTEM, I can use Windows tools or setfacl to manipulate them.

Is this simply not possible with the new scheme?

Regards -- Eliot Moss

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

Re: More about permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3492 bytes --]

On Mar 30 23:26, Eliot Moss wrote:
> Dear Cygwin community --
> 
> Along with some others, I've been struggling a little to accommodate
> the changes to permissions handling that came lately.  I think I about
> have it figured out to work mostly Unix-like within my cygwin tree,
> but have one remaining thing I am wondering about, even though I have
> been through the ntsec document more than once.  (I think everyone
> will admit that this is complicated :-) ...)
> 
> - I have created a new group, that I call Cygwin, to be the typical
>   group of cygwin-related files, so that I can control group permissions
>   appropriately. I am a member of that group.
> 
> - I have found that if a directory is chmod to 2755 (2000 == set gid)
>   and the directory's group is Cygwin, then cygwin-created files in
>   the directory get group Cygwin.  (This was not necessarily happening
>   before.)  To get this to happen, I had to list the sid of the Cygwin
>   group as my group in my line of the /etc/passwd file.  Otherwise the
>   group would be me, which does not seem to allow the same differentiation
>   of user versus group permissions.

The group s-bit is not yet taken into account.  If you have "Cygwin" as
your primary group in /etc/passwd or the account DB of choice (SAM/AD),
using 0755 as permissions should do the same thing.

Taking the group s-bit into account is part of my work-in-progress for
Cygwin 1.7.36.

> - I could not find an explanation of the 'mask' list by getfacl.  Near
>   as I can tell it is not really settable, although setfacl does not
>   complain, and it is the OR of the permissions of the various groups.

I explained that in the release annnouncement, I think.  The mask
value is required per POSIX, but it's faked on Cygwin yet, the reason
being that Windows doesn't know such a mask value.  I have an idea how
to make this work, but I need time for that.  The last two or three
weeks I had more than enough other stuff so I couldn't concentrate
on this, and it looks like this week is the same.

> Now, to what I would like to do.  Ideally I want SYSTEM to have rwx
> access to everything.  Seems a generally good idea on Windows, and at
> least r permission on files and rx on directories is needed for my
> backup program to access things.
> 
> But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls
> always lists rwx for the group part of any such file, and chmod, if
> applied, affects SYSTEM's access bits.  What I'd like is for SYSTEM's
> role here to be hidden.  If there are any files where I want to restrict
> SYSTEM, I can use Windows tools or setfacl to manipulate them.
> 
> Is this simply not possible with the new scheme?

No.  We discussed this at one point a few weeks ago, but it still seems
wrong to me to hide the permissions of any account.  Where does it end?
Is it only SYSTEM, or Administrators as well?  And then Domain Admins?
Backup Operators?  This contradicts the entire POSIX permission model.
I'm *very* reluctant to ignore accounts in permission handling.

Why does SYSTEM need full access to the files?  If it's a backup tool,
it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway.  Every tool with
Administrators in the token has the right to enable these access rights
anyway.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More about permissions

[Eliot Moss]

On 3/31/2015 6:15 AM, Corinna Vinschen wrote:
> On Mar 30 23:26, Eliot Moss wrote:

> The group s-bit is not yet taken into account.  If you have "Cygwin" as
> your primary group in /etc/passwd or the account DB of choice (SAM/AD),
> using 0755 as permissions should do the same thing.

Ok -- since I was using this mostly to try to get the primary group
inserted (instead of my user ("Eliot") as a group), this is fine for
most of my purposes.  I can see that eventually it would be nice to
get the POSIX behavior.

> Taking the group s-bit into account is part of my work-in-progress for
> Cygwin 1.7.36.

Step by step!

>> - I could not find an explanation of the 'mask' list by getfacl.  Near
>>    as I can tell it is not really settable, although setfacl does not
>>    complain, and it is the OR of the permissions of the various groups.
>
> I explained that in the release annnouncement, I think.  The mask
> value is required per POSIX, but it's faked on Cygwin yet, the reason
> being that Windows doesn't know such a mask value.  I have an idea how
> to make this work, but I need time for that.  The last two or three
> weeks I had more than enough other stuff so I couldn't concentrate
> on this, and it looks like this week is the same.

My disconnect was that I forgot this was a POSIX thing, perhaps because
none of the cygwin man pages really mentioned it.  On a POSIX system,
'man acl' explains it (I found the description of the computations of
access rights particularly clarifying).  Maybe the POSIX documentation
can be included somewhere, or a reference to it so that someone else
is not confused on this point?  I would agree that such documentation
refinement is not a high priority.

>> Now, to what I would like to do.  Ideally I want SYSTEM to have rwx
>> access to everything.  Seems a generally good idea on Windows, and at
>> least r permission on files and rx on directories is needed for my
>> backup program to access things.
>>
>> Is this simply not possible with the new scheme?
>
> No.  We discussed this at one point a few weeks ago, but it still seems
> wrong to me to hide the permissions of any account.  Where does it end?
> Is it only SYSTEM, or Administrators as well?  And then Domain Admins?
> Backup Operators?  This contradicts the entire POSIX permission model.
> I'm *very* reluctant to ignore accounts in permission handling.

I can see that it might be a slippery slope.

> Why does SYSTEM need full access to the files?  If it's a backup tool,
> it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway.  Every tool with
> Administrators in the token has the right to enable these access rights
> anyway.

I am not sure this particular program (CrashPlan) works that way.

I suppose that I am seeing SYSTEM as the moral equivalent of root in
POSIX.  In POSIX, root can access anything, and I don't believes ACLs
can lock it out.  I agree that Windows does not really have the concept
of a single 'root'.  Administrators is close, but the various aspects
of root are split up in different ways.  We're not going to get a
perfect mapping.

Maybe what I am looking for is something like this:

- Certain Windows accounts/groups would be treated as 'root' for cygwin's
   purposes, perhaps controlled by a list in a file read when cygwin starts up.

- The permissions associated with root sids would be ignored by ls, chmod,
   and such, though (we could decide) perhaps visible and settable via getfacl
   and setfacl.  (Making them visible would not be very POSIX like, but it
   might be convenient.)  Getting fancier, we could have a flag control whether
   these permissions are visible through the get/setfacl interface.

- The umask and mask would not turn off permissions associated with these
   sids.

- If the current user/group privileges allow access because they are a root
   sid and the Windows ACL grants the permission, then the permission would
   be granted (i.e., the user is effectively root in that case).

In all this I am just thinking out loud.  There is no 'perfect' way to map
between the POSIX concepts and the Windows ones.  I am just not sure we've
taken the POSIX concept of 'root' and mapped it at all, though ...

The ntsec page does a great job of describing the complexities of mapping
identities and file permissions, and of switching identities.  It does not
really address the notion of which identities are like root.  I agree that
doing this thoroughly may impact set(e)uid.  Some programs would probably
like it if running under any 'root' sid (according to my concept above)
gave an effective uid of 0.  I am not sure that could work (the real sid
might need to be saved / available as well -- sigh).

Anyway, thanks for listening ...

Regards, and thank you for your continuing work on this!    Eliot

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

Re: More about permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5801 bytes --]

On Mar 31 08:21, Eliot Moss wrote:
> On 3/31/2015 6:15 AM, Corinna Vinschen wrote:
> >On Mar 30 23:26, Eliot Moss wrote:
> >Taking the group s-bit into account is part of my work-in-progress for
> >Cygwin 1.7.36.
> 
> Step by step!

Right.  Baby steps :}

> >>- I could not find an explanation of the 'mask' list by getfacl.  Near
> >>   as I can tell it is not really settable, although setfacl does not
> >>   complain, and it is the OR of the permissions of the various groups.
> >
> >I explained that in the release annnouncement, I think.  The mask
> >value is required per POSIX, but it's faked on Cygwin yet,
> >[...]
> 
> My disconnect was that I forgot this was a POSIX thing, perhaps because
> none of the cygwin man pages really mentioned it.  On a POSIX system,
> 'man acl' explains it (I found the description of the computations of
> access rights particularly clarifying).  Maybe the POSIX documentation
> can be included somewhere, or a reference to it so that someone else
> is not confused on this point?

I would be glad if we could include the complete set of POSIX man pages
in some way, just as with the Fedora man-pages package, but I think
there are copyright issues and we have to ask the Open Group if Cygwin
is allowed to provide them.  Either way, I put this on my TODO.

> >>Is this simply not possible with the new scheme?
> >
> >No.  We discussed this at one point a few weeks ago, but it still seems
> >wrong to me to hide the permissions of any account.  Where does it end?
> >Is it only SYSTEM, or Administrators as well?  And then Domain Admins?
> >Backup Operators?  This contradicts the entire POSIX permission model.
> >I'm *very* reluctant to ignore accounts in permission handling.
> 
> I can see that it might be a slippery slope.
> 
> >Why does SYSTEM need full access to the files?  If it's a backup tool,
> >it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway.  Every tool with
> >Administrators in the token has the right to enable these access rights
> >anyway.
> 
> I am not sure this particular program (CrashPlan) works that way.

I don't know what CrashPlan is doing, but if it requires to access
*all* files, it's bound to enable the SE_BACKUP_NAME privilege in its
token.  Otherwise it's just not up to the task.

> I suppose that I am seeing SYSTEM as the moral equivalent of root in
> POSIX.  In POSIX, root can access anything, and I don't believes ACLs
> can lock it out.

Same with *any* account having the Administrators group in the user token,
and enabled (UAC).  SYSTEM has these rights.

The problem is *not* that the account doesn't have these rights, the
problem is that the SE_BACKUP_NAME privilege (which comes for free with
the Administrators group membership) is *disabled* in the token by
default, and applications have to enable it explicitely to act on this
right.  And lots of applications are plain too dumb to do that, despite
the fact that it's really easy.

Cygwin applications running under an admin account in elevated mode
have SE_BACKUP_NAME/SE_RESTORE_NAME enabled by default.  Those Cygwin
applications will have the same rights as a "root" user on U*X in
terms of file permissions.

> Maybe what I am looking for is something like this:
> 
> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>   purposes, perhaps controlled by a list in a file read when cygwin starts up.

They are automatically "root" if they are member of the "Administrators"
group, as outlined above.

> - The permissions associated with root sids would be ignored by ls, chmod,
>   and such, though (we could decide) perhaps visible and settable via getfacl
>   and setfacl.  (Making them visible would not be very POSIX like, but it
>   might be convenient.)  Getting fancier, we could have a flag control whether
>   these permissions are visible through the get/setfacl interface.

You're looking at this from a pure user-centric point of view.  Look at
it from the Cygwin DLLs view.  The Cygwin DLL is "the system".  It
provides functions like stat(2), chmod(2), chown(2), acl(2).  These
functions are used by all of the aforementioned tools.  The tools are
entirely out of the picture.  The behaviour of the above system calls is
what determines the behaviour of all of those tools.  Therefore getfacl(1)
and ls(1) get the same output.

> - The umask and mask would not turn off permissions associated with these
>   sids.

Sigh.  You have no idea how complicated that would be.  Time-consuming.
Each single permission check would have to ask a list of SIDs, etc.

>   I am just not sure we've
> taken the POSIX concept of 'root' and mapped it at all, though ...

We did,  See above.  Member of "Administrators"?  Then you're "root".
Unless running under an UAC-crippled shell.

> The ntsec page does a great job of describing the complexities of mapping
> identities and file permissions, and of switching identities.  It does not
> really address the notion of which identities are like root.  I agree that
> doing this thoroughly may impact set(e)uid.  Some programs would probably
> like it if running under any 'root' sid (according to my concept above)
> gave an effective uid of 0.  I am not sure that could work (the real sid
> might need to be saved / available as well -- sigh).

I'm not good at documentation.  I would appreciate help to explain
stuff which I didn't even mention for sheer ignorance that anybody
could not know it.  I'm working too long on this stuff to know what
people not working on this stuff don't know.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More about permissions

[Eliot Moss]

On 3/31/2015 4:55 PM, Andrey Repin wrote:

 >> I am not sure this particular program (CrashPlan) works that way.
>
> That's not program property, but the user you run the program from.

Perhaps, but it runs as a background service.  I never explicitly said what
user it runs as, etc.

Looking in Services, I see is logs on as "Local System account".  Using
Process Explorer, it appears to run without SEBackup/Restore privileges.
Since the program has to request them itself as it runs, I don't see any
good way to fix this.

> I think i've explained it earlir, but here's it again:
> In POSIX model, root have implicit permissions.
> In Windows model, there NO implicit permissions at all. Everything should be
> explicitly assigned. I.e. SeBackupRestore privilege.
> If you deny SYSTEM access to a file, OS will not be able to do anything about
> it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT.
> (And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were
> able to get around it.

Yes, I get that.  Hence my desire to grant SYSTEM:rwx on everything.

What we seem to have ended up with here, though, is that the
root privileges are explicit and are exposed in the ordinary permissions visible
with, say, ls -l.  This is not natural from a POSIX point of view (I claim);
otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX.

Now where this really makes a difference is when I am transferring files between my Windows
system and other systems that are Unix-based, using git, rsync, and such tools.
Either I remove SYSTEM access or the permissions get messed up.

>> Maybe what I am looking for is something like this:
>
>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>>     purposes, perhaps controlled by a list in a file read when cygwin starts up.

> The list would be very short. "NT AUTHORITY\SYSTEM".

Ok -- I would be happy with that, rather than having g+rwx happening to every
file because I am granting SYSTEM access.

Do you begin to see the bind I feel myself in?

Regards -- Eliot

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

Re: More about permissions

[Andrey Repin]

Greetings, Eliot Moss!

 >>> I am not sure this particular program (CrashPlan) works that way.
>>
>> That's not program property, but the user you run the program from.

> Perhaps, but it runs as a background service.  I never explicitly said what
> user it runs as, etc.

> Looking in Services, I see is logs on as "Local System account".  Using
> Process Explorer, it appears to run without SEBackup/Restore privileges.
> Since the program has to request them itself as it runs, I don't see any
> good way to fix this.

Well, then, as Corinna said, the task isn't up to the job, if it doesn't
enable necessary privileges.
Either way, this is an offtopic.

>> I think i've explained it earlir, but here's it again:
>> In POSIX model, root have implicit permissions.
>> In Windows model, there NO implicit permissions at all. Everything should be
>> explicitly assigned. I.e. SeBackupRestore privilege.
>> If you deny SYSTEM access to a file, OS will not be able to do anything about
>> it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT.
>> (And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were
>> able to get around it.

> Yes, I get that.  Hence my desire to grant SYSTEM:rwx on everything.

That's one way to solve your issue, but not a correct way.

> What we seem to have ended up with here, though, is that the
> root privileges are explicit and are exposed in the ordinary permissions visible
> with, say, ls -l.  This is not natural from a POSIX point of view (I claim);
> otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX.

> Now where this really makes a difference is when I am transferring files between my Windows
> system and other systems that are Unix-based, using git, rsync, and such tools.
> Either I remove SYSTEM access or the permissions get messed up.

That's one of the reasons why I think SYSTEM account privileges needs to be
hidden from POSIX access mask. It needs to be shown in getfacl to reduce
confusion, though, but otherwise there's no case, where hiding it could cause
any more harm, than showing it.

>>> Maybe what I am looking for is something like this:
>>
>>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>>>     purposes, perhaps controlled by a list in a file read when cygwin starts up.

>> The list would be very short. "NT AUTHORITY\SYSTEM".

> Ok -- I would be happy with that, rather than having g+rwx happening to every
> file because I am granting SYSTEM access.

> Do you begin to see the bind I feel myself in?

Do tell me? I'm perpetually caught in it.


-- 
With best regards,
Andrey Repin
Wednesday, April 1, 2015 03:47:24

Sorry for my terrible english...


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

Re: More about permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Apr  1 03:52, Andrey Repin wrote:
> > Now where this really makes a difference is when I am transferring files between my Windows
> > system and other systems that are Unix-based, using git, rsync, and such tools.
> > Either I remove SYSTEM access or the permissions get messed up.
> 
> That's one of the reasons why I think SYSTEM account privileges needs to be
> hidden from POSIX access mask. It needs to be shown in getfacl to reduce
> confusion, though, but otherwise there's no case, where hiding it could cause
> any more harm, than showing it.
> 
> >>> Maybe what I am looking for is something like this:
> >>
> >>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
> >>>     purposes, perhaps controlled by a list in a file read when cygwin starts up.
> 
> >> The list would be very short. "NT AUTHORITY\SYSTEM".
> 
> > Ok -- I would be happy with that, rather than having g+rwx happening to every
> > file because I am granting SYSTEM access.
> 
> > Do you begin to see the bind I feel myself in?
> 
> Do tell me? I'm perpetually caught in it.

Sigh.  This is really annoying from a developer's POV.

Yes, yes, I still have "ignore SYSTEM in group handling?" on my TODO
list...


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More about permissions

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Apr  1 03:52, Andrey Repin wrote:
>> > Now where this really makes a difference is when I am transferring files between my Windows
>> > system and other systems that are Unix-based, using git, rsync, and such tools.
>> > Either I remove SYSTEM access or the permissions get messed up.
>> 
>> That's one of the reasons why I think SYSTEM account privileges needs to be
>> hidden from POSIX access mask. It needs to be shown in getfacl to reduce
>> confusion, though, but otherwise there's no case, where hiding it could cause
>> any more harm, than showing it.
>> 
>> >>> Maybe what I am looking for is something like this:
>> >>
>> >>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>> >>>     purposes, perhaps controlled by a list in a file read when cygwin starts up.
>> 
>> >> The list would be very short. "NT AUTHORITY\SYSTEM".
>> 
>> > Ok -- I would be happy with that, rather than having g+rwx happening to every
>> > file because I am granting SYSTEM access.
>> 
>> > Do you begin to see the bind I feel myself in?
>> 
>> Do tell me? I'm perpetually caught in it.

> Sigh.  This is really annoying from a developer's POV.

> Yes, yes, I still have "ignore SYSTEM in group handling?" on my TODO
> list...

That's why I'm not replying to you! <3 I know it is somewhere there.
I was explaining it to Eliot.
Sorry for disturbance!


-- 
With best regards,
Andrey Repin
Wednesday, April 1, 2015 15:35:10

Sorry for my terrible english...


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

Re: OpenSSH 6.8p1-1 and keychain: can't determine fingerprint

[wilson]

I saw the following on 
https://www.cygwin.com/ml/cygwin/2015-03/msg00477.html and I've been 
having the same issue with keychain. The fix to the /usr/bin/keychain 
shell script worked as shown, but I've added information about where the 
fix belongs (in the script) later in this message. I suggest correcting 
the indentations for the proposed fix as needed.

> After updating to OpenSSH 6.8p1-1, I experienced an issue where, at 
> every login, keychain (in my .bash_profile) wrote a warning:
> 
> <snip>
> The warning:
> Can't determine fingerprint from the following line, falling back to 
> filename
> 
> A post 
> (http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 
> [1]) to an Arch Linux forum expressed a similar report, along with a 
> solution, adding a case for SHA256 or MD5: 
> https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 [2].
> 
> For clarity, that's:
> * SHA256:[0-9a-zA-Z+/=]*|* MD5:[0-9a-zA-Z+/=]*)
>     # The new OpenSSH 6.8+ format,
>     # 1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE 
> /home/barney/.ssh/id_dsa (DSA)
>     echo "$ef_line" | cut -f2 -d' '
>     ;;
> 
> I applied the changes to my /usr/bin/keychain, and the errors stopped. 
> I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1.

I applied this fix to the case statement (penultimate entry) in the 
extract_fingerprints() function (around line 800) and it does seem to 
work for me as well. I would recommend this be added as a permanent fix 
in Cygwin's package.

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

Re: OpenSSH 6.8p1-1 and keychain: can't determine fingerprint

[Kal Sze]

On 1 April 2015 at 21:03, wilson <wilson@ds.net> wrote:
>
> I saw the following on https://www.cygwin.com/ml/cygwin/2015-03/msg00477.html and I've been having the same issue with keychain. The fix to the /usr/bin/keychain shell script worked as shown, but I've added information about where the fix belongs (in the script) later in this message. I suggest correcting the indentations for the proposed fix as needed.
>
>> After updating to OpenSSH 6.8p1-1, I experienced an issue where, at every login, keychain (in my .bash_profile) wrote a warning:
>>
>> <snip>
>> The warning:
>> Can't determine fingerprint from the following line, falling back to filename
>>
>> A post (http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 [1]) to an Arch Linux forum expressed a similar report, along with a solution, adding a case for SHA256 or MD5: https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 [2].
>>
>> For clarity, that's:
>> * SHA256:[0-9a-zA-Z+/=]*|* MD5:[0-9a-zA-Z+/=]*)
>>     # The new OpenSSH 6.8+ format,
>>     # 1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE /home/barney/.ssh/id_dsa (DSA)
>>     echo "$ef_line" | cut -f2 -d' '
>>     ;;
>>
>> I applied the changes to my /usr/bin/keychain, and the errors stopped. I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1.
>
>
> I applied this fix to the case statement (penultimate entry) in the extract_fingerprints() function (around line 800) and it does seem to work for me as well. I would recommend this be added as a permanent fix in Cygwin's package.
>
>
> --
> 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
>

If you don't have to support multiple users (like me), just
downloading the 2.8.0 keychain script to your local path and sourcing
that that in .profile/.bash_profile is probably cleaner.

I seem to notice that keychain 2.8.0 is slower to load than 2.7.1 though.

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

Re: More about permissions

[Eliot Moss]

On 4/1/2015 3:38 AM, Corinna Vinschen wrote:

> Sigh.  This is really annoying from a developer's POV.

I know ...

> Yes, yes, I still have "ignore SYSTEM in group handling?" on my TODO
> list...

Thank you, Corinna.  I appreciate your efforts, not only on the coding
side but also in thinking through how best to present Windows weirdness
through a POSIX interface ...

Eliot

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

Re: More about permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

On Mar 31 20:41, Eliot Moss wrote:
> On 3/31/2015 4:55 PM, Andrey Repin wrote:
> 
> >> I am not sure this particular program (CrashPlan) works that way.
> >
> >That's not program property, but the user you run the program from.
> 
> Perhaps, but it runs as a background service.  I never explicitly said what
> user it runs as, etc.
> 
> Looking in Services, I see is logs on as "Local System account".  Using
> Process Explorer, it appears to run without SEBackup/Restore privileges.
> Since the program has to request them itself as it runs, I don't see any
> good way to fix this.
> 
> >I think i've explained it earlir, but here's it again:
> >In POSIX model, root have implicit permissions.
> >In Windows model, there NO implicit permissions at all. Everything should be
> >explicitly assigned. I.e. SeBackupRestore privilege.
> >If you deny SYSTEM access to a file, OS will not be able to do anything about
> >it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT.
> >(And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were
> >able to get around it.
> 
> Yes, I get that.  Hence my desire to grant SYSTEM:rwx on everything.
> 
> What we seem to have ended up with here, though, is that the
> root privileges are explicit and are exposed in the ordinary permissions visible
> with, say, ls -l.

Huh?  ls -l (that is, stat(2)) shows the permissions in the same way as
they are computed on a POSIX system.  The mask value is just faked from
the existing permsissions, but other than that, it does what POSIX
1003.1e requires.

> This is not natural from a POSIX point of view (I claim);
> otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX.

I don't grok that.  POSIX shows the permissions exactly as they are,
with the group permissions being the primary group perms or the mask
value if there is a mask.  On Cygwin the mask is faked, but it shows the
combined permissions of all non-primary users and groups, so it's a good
fake.  So in both cases the group permissions show you where's a
security problem.

Granting SYSTEM access to the kitchen sink is a Windows thingy, and a
bad one as well.  Rather than just asking the developers to enable the
SE_BACKUP_NAME/SE_RESTORE_NAME rights when needed, they now add full
access for SYSTEM and Administrators by default every time.  That's a
bad hack and totally unnecessary, too.

But Cygwin adds SE_BACKUP_NAME/SE_RESTORE_NAME rights to the processes
by default, so in theory you don't need full SYSTEM access inside your
Cygwin tree.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

OpenSSH 6.8p1-1 and keychain: can't determine fingerprint

[White, W John (GE Transportation)]

After updating to OpenSSH 6.8p1-1, I experienced an issue where, at
every login, keychain (in my .bash_profile) wrote a warning:

My .bash_profile lines:
# Start keychain, passing as args all private keys to be cached
keychain ${HOME}/.ssh/id_dsa #, other_key1, other_key2, ...
# That creates a file which must be sourced to set env vars
source ${HOME}/.keychain/${HOSTNAME}-sh

The warning:
Can't determine fingerprint from the following line, falling back to filename

A post
( http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 )
to an Arch Linux forum expressed a similar report, along with a solution,
adding a case for SHA256 or MD5:
https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 .

For clarity, that's:
*\ SHA256:[0-9a-zA-Z\+\/=]*|*\ MD5:[0-9a-zA-Z\+\/=]*)
    # The new OpenSSH 6.8+ format,
    #   1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE /home/barney/.ssh/id_dsa (DSA)
    echo "$ef_line" | cut -f2 -d' '
    ;;

I applied the changes to my /usr/bin/keychain, and the errors stopped.

I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1 .

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