Hello Erich,
"So only the user 'test' has access to this file based on the ACL and
no others? Logged in as Administrator, can you navigate, see, open, and save the
file in subfolder1 via Windows Explorer?"
Of course not, but this is normal Windows behaviour. The Backup-API is the way, to solve this.
Quote from MSDN-Library:
"In most cases, the ability to read and write the security settings of a file or directory object is restricted to kernel-mode processes. Clearly, you would not want any user process to be able to change the ownership or access restriction on your private file or directory. However, a backup application would not be able to complete its job of backing up your file if the access restrictions you have placed on your file or directory does not allow the application's user-mode process to read it. Backup applications must be able to override the security settings of file and directory objects to ensure a complete backup. Similarly, if a backup application attempts to write a backup copy of your file over the disk-resident copy, and you explicitly deny write privileges to the backup application process, the restore operation cannot complete. In this case also, the backup application must be able to override the access control settings of your file.
The SE_BACKUP_NAME and SE_RESTORE_NAME access privileges
were specifically created to provide this ability to backup applications.
If these privileges have been granted and enabled in the access token of
the backup application process, it can then call CreateFile to open
your file or directory for backup, specifying the standard READ_CONTROL
access right as the value of the dwDesiredAccess parameter. However,
to identify the calling process as a backup process, the call to CreateFile
must include the FILE_FLAG_BACKUP_SEMANTICS flag in the dwFlagsAndAttributes
parameter."
If I would have to guess what happens,
I would say bacula is using this privilege for reading object to backup,
but not for browsing the directory-tree. But of course usually things aren't
that easy :-)
Greetings
Christoph
| Erich Prinz <[EMAIL PROTECTED]>
10.04.2006 20:08 |
|
Hi Christoph,
This has got to be a thorn in your side! Grrrrrrrrr.
"Accessible only for test means, that user test is the owner of that
filesystem object an the only entry in the ACL as well."
So only the user 'test' has access to this file based on the ACL and
no others?
Logged in as Administrator, can you navigate, see, open, and save the
file in subfolder1 via Windows Explorer?
Odd that the ACL allows access all the way to subfolder1 but not
subfile1. If all checks out above, seems to me to be a FD issue. Kern
released a new build (see prior links below) and may be worth
attempting using the latest build.
Erich
On Apr 10, 2006, at 12:09 PM, [EMAIL PROTECTED] wrote:
>
> Hello,
>
> as reported here some time ago, I have problem with the bacula FD
> in a Win2K domain controller. I get "Access is denied" errors for
> files, which are not accessible to the user running the FD-process.
> As bacula is using the windows backup API, this should work anyway.
>
> Now, I created virtual machines for testing purposes and detected,
> that there is no difference between domain controllers and other
> windows installation, as I said before. It just happened that I
> didn't made the testing situation as complicated as it is on the
> domain controller. Everything works fine, even on a domain
> controller, if the unaccessible file lies in an accessible
> directory. Thats the only case I tested up to now. But access
> denied errors occur, if you have this situation:
>
> System: Out of the Box Win2K server installation (SP4)
>
> Users:
> Administrator
> test
>
> Directory structure:
>
> folder1 (Accessible for everyone)
> - file1 (accessible only for test)
> - subfolder1 (accessible only for test)
> - subfile1 (accessible only for test)
>
>
> In this case, file1 ist backed up correctly as well as subfolder1.
> An error occurs for subfile1. Accessible only for test means, that
> user test is the owner of that filesystem object an the only entry
> in the ACL as well.
>
> This seams to be a bug to me rather than a configuration issue, or
> does anybody have any idea?
>
> Thanks in advance
> Christoph
>
