[Box Backup-dev] Windows ACLs

[Chris Wilson]

Hi Charles,

On Mon, 27 Feb 2006, Charles Lecklider wrote:

>> 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.

That's a restore client user interface issue. There must be a lot of 
options of how to achieve this without interrupting the user too much, but 
still making them aware that the permissions were not restored completely, 
and they may still have some work to do. IMHO, it's not a good argument 
for not backing up the ACLs at all, or for not trying to restore them.

It seems to me that if the permissions restore correctly, the user has 
nothing to worry about; if they do not, then we can warn the user, and 
they have the choice to make a better mapping if provided with enough 
information by the restore client, or to ignore it if they don't feel like 
messing about with the permissions. If we don't even back them up, there's 
nothing we can do to help or warn the user at restore time.

Surely other backup software must deal with permissions? Any ideas about 
how they do it without bothering the user too much?

>> 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.

They are not necessarily using roaming profiles, nor storing all their 
data on the server. You have to be pretty rich, or have minimal 
requirements, to be able to keep all your staff's data on the server, and 
there's no guarantee that the staff actually will. And if they do, then 
there's no need to run Box on the client, as you said. I'm more concerned 
about using Box to back up servers, and clients with important data on 
their disks (not in their profile).

>> 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.

Can we detect that automatically? And if so, how?

>> 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.

Again, that's a client interface issue. We can simply report "You don't 
have permission to restore the original access controls on this file", or 
"The original owner of this file does not exist on this machine", as a 
warning in the restore log, and continue without disturbing the user too 
much.

If you don't want the users to call you, how about not leaving their 
precious pr0n wide open to the managing director after a restore? :-)

> 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.

Why is he restoring permissions, you ask? Well, I'm no Windows admin, in 
fact I hate the platform, but what I hate even more is the fact that so 
many trivial tasks require so much laborious interaction. If it's at all 
possible to restore the original permissions, or some semblance of them, 
then why not offer the admin the option to do so, and save him from the 
slavery of doing it all by hand?

And that's assuming that the permissions are obvious and could be restored 
by hand. Consider a shared directory where many people have created files, 
and some have restricted access to others for certain files in that 
directory. Without the ACLs having been backed up in the first place, how 
on earth would he know what the permissions ought to be?

> 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?

It would only get the right permissions IF the container still has them 
(i.e. the permissions being borked is not why he's restoring in the first 
place), AND there were no explicit entries or special inheritance flags on 
the file itself. I can see many possible cases where one or both of those 
assumptions is broken.

If restoring to a different place, the files were assigned particular 
permissions for a reason, and they should not be discarded lightly. Why 
should they not make sense in the new location?

> 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.

We can take inheritance into account. It's not rocket science, after all
Windows does it, and Microsoft's programmers aren't all that smart :-) 
It's a bit tricky, and requires careful programming as you pointed out, 
but it's not impossible. I think that what we'd have to do is back up ALL 
permissions, including inherited ones, on the location root directory, and 
only explicit iones and flags on the subdirectories and files within it.

Then at restore, we can work out what permissions should apply to the root 
folder we're restoring, by working back up the tree to the location root; 
make it so, with a full override DACL if necessary; and then apply the 
explicit entries and flags to the folders and files within, as normal. 
Wouldn't that work?

> 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.

That's fine, we restore recursively, so we can apply the permissions to a 
folder after we've restored all of its contents. In the mean time, we can 
grant ourselves full access, and no access to anyone else, while restoring 
the contents.

> 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.

I see what you mean, but most users are far less paranoid (no offence), 
and will happily run the restore client as themselves or as an 
administrator. If we can't restore the original file permissions when 
running as a normal user, we can at least warn them, so that they know 
what the original permissions were, and can apply appropriate permissions 
to the restored files if they care.

Cheers, CHris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |