[Box Backup-dev] Windows ACLs

[Charles Lecklider]

Chris Wilson wrote:
> Hi Charles,
> 
>>> Doesn't it make sense to try to back up and restore that DACL, just
>>> as we back up and restore file permissions on Unix?
>>
>> No:
>>
>> 1) He was restoring onto a new machine, so none of the raw SIDs would
>>    match. If we stored the names it would only work if he used the
>> same    username on the new machine.
> 
> I was considering using names instead of SIDs. If the specified user
> does not exist on the new machine, we can always report the problem to
> the user doing the restore, who presumably will know what a sensible
> mapping would be.

They will? I was hoping the end user would be able to use the GUI to
restore their own files, but if it gripes about broken accounts that
would quickly be more trouble that it's worth.

> I also imagine that in many cases (admittedly not all), the old and new
> machines would be members of the same domain, and thus it's likely that
> most of the SIDs of files that we would consider restoring would be
> domain SIDs rather than local ones, and still valid on the new machine.

If they're part of the same domain then they are probably using roaming
profiles too, in which case Box wouldn't be needed on the client; you
just need to login to the new machine and everything gets copied back
from the server.

>> 2) The files will automatically get their permissions from the
>> directory    they're restored into. Because of the way ACL inheritance
>> works from    Win2k onwards it's quite hard to change them to what's
>> stored without    breaking things quite badly. It's surprisingly easy
>> to get a null    DACL, which in contrast to a NULL SD actually denies
>> access to    everyone....
> 
> Sorry, what is a null DACL? Is it a DACL with no EXPLICIT_ACCESS
> entries? How does one avoid creating one?

It's not that you have to avoid creating one, it's that Windows
sometimes treats what you think is a valid DACL as a null DACL. It's
almost always because you got the inheritance flags ever so slightly
wrong, and it's a nasty surprise because you can't just set it again -
you have to take ownership first.

>> 3) SIDs can become orphaned - usually when users are deleted, but also
>>    temporarily if no domain controller is available. I suppose we
>> could    store a textual representation of them, but that starts
>> getting    pretty nasty.
> 
> Thanks for reminding me of this. If the SID doesn't have a user name
> mapping, could we not back up the SID, on the assumption that it may be
> restored to the same machine, and in that case we would want to restore
> the original SID, orphaned or not? If restored to a different machine,
> it would seem to make sense to warn the user, as above, and let them
> take appropriate action.

I guess it depends on who your target user is.

I want a normal user to be able to restore their own files without
having to phone me. Messages about SIDs, while guaranteed to induce
interesting questions ("who is this SID guy? there's noone here called
Sid"), aren't in the slightest bit helpful to the end user.

Now, if you're expecting an Administrator to be doing the restoring,
fine, warn away. But, answer me this: if the admin is restoring the
files, why is he restoring the permissions? It'd be far simpler just to
set them again than to clean up the mess Box will make of the inheritance.

Most of the time the file is going to be restored in-place. That means
that most of the time it will automatically get the right permissions.
Why mess with them? If it isn't going to be put in the same place, who's
to say those permissions make any kind of sense?


I know I keep going on about inheritance, but it really is a problem. If
you don't get the order of the ACL exactly correct you end up with
something that simply doesn't work properly. Worse, unless you create a
protected DACL on every single file you restore (and if some software
did that to me as an admin I'd put a bounty on the writer's head because
that's *really* anti-social), you have to take into account the ACEs
that are going to be inherited from the directory.

Worse, if you're going to restore a whole directory, you have to take
into account the order in which you restore things, because the
inheritance kicks in as soon as you create the directory.


Also, restoring permissions forces us to have a service running with a
load of privileges. My view is that the risk of having that service
outweighs the rather dubious benefit of being able to restore ACLs. If
we don't restore ACLs then we can run with no privileges and impersonate
the client end of the pipe when we need to do any work - far safer.

-C