Re: SFTP ACLs need inheritance support

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

denis bider wrote:
>> Hmmm... I was thinking of these as simply enabling the 
>> backup or restore privilege which bypasses access checks--
>> which would be highly useful for things like scanning the
>> volume to see who is using what space--
> 
> Based on my reading in the past few days (but not actual
> first-hand experience), it seems that Windows always requires
> not just a privilege but also a flag; i.e. the
> "SeSecurityPrivilege" goes hand in hand with
> ACCESS_SYSTEM_SECURITY flag (one is not useful without the
> other), and the "SeBackupPrivilege" goes hand in hand with the
> FILE_FLAG_BACKUP_SEMANTICS flag.
> 
> In other words, it is my understanding that you have to
> specify FILE_FLAG_BACKUP_SEMANTICS in order to get any kind of
> special behavior from Windows, and FILE_FLAG_BACKUP_SEMANTICS
> in turn means that you'll be reading from the backup stream,
> and you can't have one without the other.

FILE_FLAG_BACKUP_SEMANTIC in combination with
SeBackupPrivilege bypasses the read access checks
in the filesystem.

It doesn't require you to use BackupRead() or BackupWrite()
to my knowledge-- in other words, it is perfectly
reasonable to open a file file FILE_FLAG_BACKUP_SEMANTIC
and still call ReadFile/WriteFile.

So in fact, if an application wanted to make
tar file backups using the SFTP protocol,
it could do so by specifying ACCESS_PRIV_BACKUP_FILE
but not specifying SSH_FXF_ACCESS_BACKUP_STREAM.

However, if ACCESS_PRIV_BACKUP_FILE implied that
READ and WRITE data should return the backup
stream (which it would have to in order to
backup alternate data streams) it would no
longer be possible to do a tar file backup.

Thanks,

Joseph


PS. I'm tempted, as a win32 extension, to allow
a file to be opened as a directory in order to
enumerate the named streams.