X-Spam-Check-By: sourceware.org
Date: Mon, 16 Oct 2006 15:14:17 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Permission to read anything from ls, cp, and find?
Message-ID: <20061016131417.GV8323@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20061012202458 DOT GA24871 AT panix DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20061012202458.GA24871@panix.com>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Oct 12 16:24, David Arnstein wrote:
> I have a bash shell script that I run every night using Windows task
> scheduler. The purpose of this script is to take an inventory of my
> PC, and to make copies of a few important files. The script calls ls,
> find, cp, and a few other ordinary Linux/Unix utilities.
> 
> My problem is that the script does not have sufficient privilege to
> read every file on my PC. If I run the script as user Administrator,
> it fails to inventory certain files owned by SYSTEM. If I run the
> script as user SYSTEM, it fails to inventory many files owned by
> ordinary users.
> 
> I suspect there is a solution to this problem. I use a commercial
> backup software product that certainly does not have this problem.
> 
> How to list and copy every file on a PC using Cygwin utilities?

Right now you have no chance to do that.  I investigated some time into
this and I found two problems which spoil what you're trying to do.

First, Cygwin doesn't try to open files for backup intent by default.
This disallows to open files for a backup with, say, tar(1), if the
calling process has no read permissions on a file, even if the backup
privilege is present in the processes access token.

Second, surprisingly the NT authorization function AccessCheck doesn't
take the backup and restore privileges of the access token into account.
I couldn't believe that at first, but all my tests showed that this is
the case.  The result is that access(2) fails on files and directories
for which the calling user has no access per the ACL, regardless of
having backup/restore privilege.  This is pretty unfortunate.  A side
effect is that opendir(3) also fails since opendir(3) calls access(2).

I applied a patch which is intended to solve this problem.  Please try
the next developers snapshot from http://cygwin.com/snapshots/

Please be aware that one problem remains.  The Windows function
SetCurrentDirectory, which is the base function used by chdir(2),
apparently tries to open the directory in which to change without using
the FILE_OPEN_FOR_BACKUP_INTENT flag.  This has the effect that chdir
fails when the process has no sufficient permissions on the directory
even if it has backup privileges.  This is also very unfortunate, since,
for instance, find(1) traverses directory trees by chdir'ing into
directories before listing them.  So even with this patch, find(1) is
still not a good candidate for backing up directory trees in a situation
as you describe above.  tar(1) doesn't seem to have this problem,
though.


Corinna

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

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