Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at