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 p
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 presumab
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
SeRestorePr
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
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 pr
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 ba
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 no
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 ask
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 (dir
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
f
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
f
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
12 matches
Mail list logo