Request to the git maintainer

Request to the git maintainer

[Eliot Moss]

Dear maintainer of git ....

I use CrashPlan as my backup engine.  It has difficulty backing up
files with no "other" access.  Many git locale (.mo) and doc-related
files have permissions 600 (directories 700).  Is there a good reason
for this?  I would think that 644 and 755 access would be fine for
these files, and it would prevent the problems I see with CrashPlan.

For the moment I have changed the access modes locally, but I suspect
that future updates will cause reversion unless this is fixed upstream.

(If there are other files out there in the Cygwin universe whose
"other" access is denied for no good reason, I would ask the same
for them :-) ...)

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: Request to the git maintainer

[Achim Gratz]

Eliot Moss writes:
> Dear maintainer of git ....
>
> I use CrashPlan as my backup engine.  It has difficulty backing up
> files with no "other" access.  Many git locale (.mo) and doc-related
> files have permissions 600 (directories 700).  Is there a good reason
> for this?  I would think that 644 and 755 access would be fine for
> these files, and it would prevent the problems I see with CrashPlan.

That's an upstream build system bug.  Some of the installation scripts
use cp instead of install and that in turn makes them dependent on umask
(which doesn't get set aywhere I can easily find).  I guess Adam could
work around that by setting 'umask 022' in the cygport file, but it
really should be fixed in git.git.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: Request to the git maintainer

[Eliot Moss]

On 7/10/2017 4:24 PM, Achim Gratz wrote:
> Eliot Moss writes:
>> Dear maintainer of git ....
>>
>> I use CrashPlan as my backup engine.  It has difficulty backing up
>> files with no "other" access.  Many git locale (.mo) and doc-related
>> files have permissions 600 (directories 700).  Is there a good reason
>> for this?  I would think that 644 and 755 access would be fine for
>> these files, and it would prevent the problems I see with CrashPlan.
>
> That's an upstream build system bug.  Some of the installation scripts
> use cp instead of install and that in turn makes them dependent on umask
> (which doesn't get set aywhere I can easily find).  I guess Adam could
> work around that by setting 'umask 022' in the cygport file, but it
> really should be fixed in git.git.

So should I post a request there, or should Adam?

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: Request to the git maintainer

[Eliot Moss]

On 7/10/2017 4:24 PM, Achim Gratz wrote:
> Eliot Moss writes:
>> Dear maintainer of git ....
>>
>> I use CrashPlan as my backup engine.  It has difficulty backing up
>> files with no "other" access.  Many git locale (.mo) and doc-related
>> files have permissions 600 (directories 700).  Is there a good reason
>> for this?  I would think that 644 and 755 access would be fine for
>> these files, and it would prevent the problems I see with CrashPlan.
>
> That's an upstream build system bug.  Some of the installation scripts
> use cp instead of install and that in turn makes them dependent on umask
> (which doesn't get set aywhere I can easily find).  I guess Adam could
> work around that by setting 'umask 022' in the cygport file, but it
> really should be fixed in git.git.

I looked upstream, and at least some of the files I am concerned about
are installed using "tar" piped to another "tar", with umask 022 set
explicitly.  I think the problem is that the source of this copying
has 600 or 700 permissions.  Not sure if *that* is an upstream problem
or not ...

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: Request to the git maintainer

[Kaz Kylheku]

On 10.07.2017 14:02, Eliot Moss wrote:
> On 7/10/2017 4:24 PM, Achim Gratz wrote:
>> Eliot Moss writes:
>>> Dear maintainer of git ....
>>> 
>>> I use CrashPlan as my backup engine.  It has difficulty backing up
>>> files with no "other" access.  Many git locale (.mo) and doc-related
>>> files have permissions 600 (directories 700).  Is there a good reason
>>> for this?  I would think that 644 and 755 access would be fine for
>>> these files, and it would prevent the problems I see with CrashPlan.
>> 
>> That's an upstream build system bug.  Some of the installation scripts
>> use cp instead of install and that in turn makes them dependent on 
>> umask
>> (which doesn't get set aywhere I can easily find).  I guess Adam could
>> work around that by setting 'umask 022' in the cygport file, but it
>> really should be fixed in git.git.
> 
> I looked upstream, and at least some of the files I am concerned about
> are installed using "tar" piped to another "tar", with umask 022 set
> explicitly.  I think the problem is that the source of this copying
> has 600 or 700 permissions.  Not sure if *that* is an upstream problem
> or not ...

I would say, get a backup system that handles whatever bits you have
on your disk, or find out how to configure the existing one.

If there are some permission problems, maybe it needs more privilege
to do its job.

You can't ask every vendor of everything that you have installed
or "git pulled" to fix their permissions because your backup program
has bizarre limitations.



--
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: Request to the git maintainer

[Eliot Moss]

On 7/10/2017 6:27 PM, Kaz Kylheku wrote:
> On 10.07.2017 14:02, Eliot Moss wrote:
>> On 7/10/2017 4:24 PM, Achim Gratz wrote:

> You can't ask every vendor of everything that you have installed
> or "git pulled" to fix their permissions because your backup program
> has bizarre limitations.

I'm not asking "every vendor".  I'm asking a limited number of
cygwin port maintainers (and so far only one specifically).

CrashPlan does not have "bizarre" limitations -- it quite
naturally has some difficulty if a file's access does not grant
it permission.

The permissions on these files is what is bizarre.  There is no
good reason they should deny read access.

Windows does not really have an equivalent of "root" that can
access anything, so there is not really any privilege I can
give the backup tool that is guaranteed to work in all cases.

I can fix the access mode manually, but every time there is an
update to the package, it will revert, so that's not a great
solution.

Beyond that, I'm not going to argue with you, Kaz.

Regards to you all -- 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: Request to the git maintainer

[Erik Soderquist]

On Mon, Jul 10, 2017 at 7:17 PM, Eliot Moss  wrote:
> I'm not asking "every vendor".  I'm asking a limited number of
> cygwin port maintainers (and so far only one specifically).
>
> CrashPlan does not have "bizarre" limitations -- it quite
> naturally has some difficulty if a file's access does not grant
> it permission.

In my experience, that is a bizarre limitation; I have yet to work
with a Windows backup program that does not have the ability to bypass
permissions when performing a backup or restore when it has been
properly configured.  Even simple robocopy has this option.

> The permissions on these files is what is bizarre.  There is no
> good reason they should deny read access.

I work with a lot of customers where the opposite perspective is taken
for security and confidentiality reasons -- if you don't have a very
strong reason to allow access, you deny by default.

> Windows does not really have an equivalent of "root" that can
> access anything, so there is not really any privilege I can
> give the backup tool that is guaranteed to work in all cases.

Windows does have its backup operators set of permissions, allowing
the backup processes to archive and restore files the user would not
normally have access to without changing those permissions and even
with restoring the permissions as they were archived.  I would check
with the CrashPlan admins for why they are not using the backup
operators permissions.

> I can fix the access mode manually, but every time there is an
> update to the package, it will revert, so that's not a great
> solution.

You should not have to change the file permissions, regardless of what
they are; Windows based backup software should not be having a problem
with the existing permissions.

-- Erik

--
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: Request to the git maintainer

[Brian Inglis]

On 2017-07-10 17:17, Eliot Moss wrote:
> On 7/10/2017 6:27 PM, Kaz Kylheku wrote:
>> On 10.07.2017 14:02, Eliot Moss wrote:
>>> On 7/10/2017 4:24 PM, Achim Gratz wrote:
> 
>> You can't ask every vendor of everything that you have installed
>> or "git pulled" to fix their permissions because your backup program
>> has bizarre limitations.
> 
> I'm not asking "every vendor".  I'm asking a limited number of
> cygwin port maintainers (and so far only one specifically).
> 
> CrashPlan does not have "bizarre" limitations -- it quite
> naturally has some difficulty if a file's access does not grant
> it permission.
> 
> The permissions on these files is what is bizarre.  There is no
> good reason they should deny read access.
> 
> Windows does not really have an equivalent of "root" that can
> access anything, so there is not really any privilege I can
> give the backup tool that is guaranteed to work in all cases.

Backup processes should run with SeBackupPrivilege.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Request to the git maintainer

[Eliot Moss]

> Backup processes should run with SeBackupPrivilege.

Reasonable.  CrashPlan runs using SYSTEM access.  I
will try adding SYSTEM to the BackupOperators group,
which presumably has SeBackupPrivilege (and
SeRestorePrivilege).  I am not sure how else to approach
granting suitable privilege to this program.

Regards - EM

--
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: Request to the git maintainer

[Brian Inglis]

On 2017-07-10 20:00, Eliot Moss wrote:
>> Backup processes should run with SeBackupPrivilege.
> 
> Reasonable.  CrashPlan runs using SYSTEM access.  I
> will try adding SYSTEM to the BackupOperators group,
> which presumably has SeBackupPrivilege (and
> SeRestorePrivilege).  I am not sure how else to approach
> granting suitable privilege to this program.

Normally (a) backup/restore account(s) with backup/restore GPOs.
Failing that, registry tweaks, which should be set up by your backup package
installer.
Review
https://support.crashplan.com/Troubleshooting/Unable_To_Back_Up_Files_Windows

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Request to the git maintainer

[Eliot Moss]

On 7/10/2017 10:33 PM, Brian Inglis wrote:
> On 2017-07-10 20:00, Eliot Moss wrote:
>>> Backup processes should run with SeBackupPrivilege.
>>
>> Reasonable.  CrashPlan runs using SYSTEM access.  I
>> will try adding SYSTEM to the BackupOperators group,
>> which presumably has SeBackupPrivilege (and
>> SeRestorePrivilege).  I am not sure how else to approach
>> granting suitable privilege to this program.
>
> Normally (a) backup/restore account(s) with backup/restore GPOs.
> Failing that, registry tweaks, which should be set up by your backup package
> installer.
> Review
> https://support.crashplan.com/Troubleshooting/Unable_To_Back_Up_Files_Windows

Thank you, Brian - I was aware of that page.  It says that the SYSTEM user
needs access to the files.  I have normally set up so that my cygwin tree
is granted SYSTEM read access all the way down.  /usr/share/locale does
not seem to obey that, which I will inspect more deeply.  Meanwhile, I am
still seeing if adding SYSTEM to BackupOperators is helpful ...

Regards - EM

--
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: Request to the git maintainer

[Eliot Moss]

On 7/11/2017 8:34 AM, Eliot Moss wrote:
> On 7/10/2017 10:33 PM, Brian Inglis wrote:
>> On 2017-07-10 20:00, Eliot Moss wrote:
>>>> Backup processes should run with SeBackupPrivilege.
>>>
>>> Reasonable.  CrashPlan runs using SYSTEM access.  I
>>> will try adding SYSTEM to the BackupOperators group,
>>> which presumably has SeBackupPrivilege (and
>>> SeRestorePrivilege).  I am not sure how else to approach
>>> granting suitable privilege to this program.
>>
>> Normally (a) backup/restore account(s) with backup/restore GPOs.
>> Failing that, registry tweaks, which should be set up by your backup package
>> installer.
>> Review
>> https://support.crashplan.com/Troubleshooting/Unable_To_Back_Up_Files_Windows
>
> Thank you, Brian - I was aware of that page.  It says that the SYSTEM user
> needs access to the files.  I have normally set up so that my cygwin tree
> is granted SYSTEM read access all the way down.  /usr/share/locale does
> not seem to obey that, which I will inspect more deeply.  Meanwhile, I am
> still seeing if adding SYSTEM to BackupOperators is helpful ...

The answer to the latter question is no, so, I applied these changes to
my /usr hierarchy (32 and 64 bit):

Directories:
   setfacl -m group:SYSTEM:r-x
   setfacl -m default:group:SYSTEM:r-x
   chgrp Cygwin
   chmod g+s

Files:
   setfacl -m group:SYSTEM:r-x
   chgrp Cygwin

The chgrp and chmod are not the more necessary parts, but they tend to
help Cygwin tools run ore smoothly.  (Cygwin is the name of a group I
set up for Cygwin things; of course I am a member of that group.)  The
setfacl SYSTEM settings are what is crucial for CrashPlan.

Meanwhile, I still claim that 600 mode for .mo files is strange :-) ...

Regards - EM

--
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: Request to the git maintainer

[Achim Gratz]

Eliot Moss writes:
> I looked upstream, and at least some of the files I am concerned about
> are installed using "tar" piped to another "tar", with umask 022 set
> explicitly.  I think the problem is that the source of this copying
> has 600 or 700 permissions.  Not sure if *that* is an upstream problem
> or not ...

That'd still be a bug, then.  If those files get installed by some other
user than the one trying to use them they'd be inaccessible, both on
UN*X and Windows.

I've checked what openSUSE does and they just enter the build script
with a 'umask 022'.  I didn't find any patch that fixes up the
permissions later, So that seems to be enough.  I'd try to build that
way first. [later…] Yup, just setting the umask to some 022 before
building the packages does the right thing on Cygwin, too.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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