Re: [boost] big problem with dependency changes

Subject: Re: [boost] big problem with dependency changes
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-06-19 04:22:11

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