On 19/06/2014 04:56, Bjørn Roald wrote:
The problem is to enable symlink support in a simple robust way that does not sacrifice security for users that dont have this by default. On Windows I fail to find a way. I think solving that should be a primary goal now, but it seems we need more detailed understanding of Windows privileges and UAC than I posses.
What about two-way sync, as I suggested earlier?
Could we possibly write or download an executable that work around this UAC strap-down and create symbolic links for Windows users in the Administrator group that has the SeCreateSymbolicLinkPrivilege set. If that is possible, then a sensible workaround would be feasible. I worry it is not possible, but I will be happy if I am wrong.
I think the only way that could work is if a system-level (and thus admin-permissions) service were installed that accepted requests from non-admin users to create symlinks on their behalf. (I hope the security pitfalls of such a thing are obvious to everyone.) It actually gets weirder than that, though. It's possible for a user with administrator rights to enable the symlink creation privilege for all users. After doing that, though, if UAC is still enabled then while any limited user would be able to create symlinks, the admin user will still only be able to do so from an elevated process. (This is because this is one of the privileges that is explicitly denied to the restricted token created for non-elevated-admin-user processes -- and as far as I'm aware there isn't a setting for *that*.) And yes, that's very weird. (Though it's true that symbolic links can be dangerous things, and it's true that most Windows apps aren't expecting them, which can make them even more dangerous. Traversing through symlinks to delete subfolders will ruin many a day.)
Down the road there are other options than staging of headers in the legacy monolithic boost folder structure. This may be achieved relatively simply by module level dependencies and multiple -I statements to the compiler. But this approach has its own set of disadvantages and a number of boost tools are not ready for it. There are probably a few pitfalls as well with dubious workarounds, e.g. command line limitations on some systems.
Another possible pitfall is that it may delay detection of cases when different libraries clobber each others' header files (although the naming policies and directory structures should limit this).