Hacker News Reader

Comment by vic-traill | Hacker News Reader

> Now in Windows 10 Creators Update, a user (with admin rights) can first enable Developer Mode, and then any user on the machine can run the mklink command without elevating a command-line console.

So an Administrator-equiv account still needs to be in the chain of events to make this useful on a per machine basis?

If this is the case I'm not sure how this makes symbolic links more useful to me in a Windows environment... ?

By default access to remote (network) symbolic links is disabled . You can enable it with fsutil [0].

Between the need for admin-equiv for mklink and the per-computer requirement to fsutil-enable sym links on network shares, symbolic links are unusable in a Windows environment.

I don't see how this feature changes that.

[0]https://blogs.msdn.microsoft.com/junfeng/2012/05/07/the-symb...

[edit: fixed typo on 'fsutil', 'sym' and 'symbolic links'. The curse of posting on a mobile device]

View on HN

There are a number of security issues which can come with symbolic links, especially with how user/group permissions are handled. There is also a lack of support for them in the ecosystem, which could introduce some strange problems (for example, whether specific apis follow them, or not). So I can understand why they're putting this behind a flag.

Like what? I can make symlinks all the live long day on unixy systems without it security problems and without having to log in as root.

Do you mean unusable in an environment where you are not a privileged user? Like locked down work/corp environments?

Yes - absolutely. Why does Joe/Joan User have to rely on their Admin having a clue to use this Feature?

We're talking symbolic links here. This is a very handy and convenient feature in userspace. Or, it should be.

In those scenarios I imagine it can be enabled via AD group policies.

If you're provisioning lots of Windows machines, why not just make these two commands part of that process?

For me the issue is more that software like version control systems and archiver utitlities that need to understand and create symlinks, might just continue to not support symlinks on Windows. When the software is running as an unprivileged user, it will still fail be able to create symlinks by default, which doesn't make the feature very enticing to add and support for the developers of the software. Git has been in that category, I don't know if this is enough to trigger a change or not. Here's hoping...

I'll take some a kick at provisioning this via GPO on Monday.

I suppose the issue at hand here is that - at minimum - it appears that use of symbolic links requires a Group Policy that specifies both support for mklink and fsutil to be configured, the former requiring admin-equivilency to enable symbolic links to work for a non-admin user.

As someone who grew up using 'ln -s' in userspace to create symbolic links, this seems to be a rather high barrier to use of a very convenient user function - "Want to use symbolic links for convenience? Have your admin create GPOS to facilitate this" seems a half-assed answer....

In my opinion the magnitude of these problems is massively increased by locked down environments where playing with something has time costs for multiple people. The time for someone to play on their machine vs the time fire b that someone to work with an administrator to request, create and test.

I absolutely agree.

How much upstream effort must occur to facilitate downstream userspace day-to-day function(s)?

[edit]

I'll perform whatever action is required to enable user functionality. That's what I'm here for.

But I don't agree/understand why the user-use of something as basic as symbolic links is dependent on an Admin having a clue.

I agree with you, it shouldn't require admin intervention. But I think the reason it annoys you, other sysadmins and developers alike is because the security model is broken in terms of UX, velocity and innovation.

From strictly a security perspective we need to lock down machines and remove admin rights because clients are a serious threat to our internal networks. But we pay out the nose in terms of productivity, employee happiness, innovation, etc. Even if Microsoft fixes all of these little things that currently require careful thought by a sysadmin before deploying that's just Microsoft. There's still plenty of poorly written software out there that requires admin rights. And that's new software, not legacy. Requiring sysadmin intervention every time someone wants to try something, especially just on a local machine is a huge drag on everyone involved.

Right now the idea is still young and as far as I know hasn't been productized yet but it looks a lot like Google's Beyond Corp[0] system of shrinking the perimeter to exclude clients, treat them as potentially hostile by default and have access to resources based on a dynamic threat assesment seems like the best way forward. Users have flexibility and freedom and the company is protected. But I think it's still out of reach for most companies. It will take projects and products to make it feasible and even then a lot of companies are still struggling to do basic "hard outside squishy interior" properly.

[0] http://research.google.com/pubs/pub43231.html

I'm assuming that this initial admin step is due to the plethora of edge cases in Windows that exist when it comes to symbolic links (old APIs being the most probable cause, but there may be issues in the current FS permissions model). If MS just enable this functionality now, with no extra steps required, in the main stream release, then they will leave themselves open to a bunch of potential security issues and nasty bugs.

Hopefully they'll act on the feedback of the insider-track release users, and those enabling developer mode in the more stable releases, and this will iron out the vast majority of problems before they just enable it by default for all users.

I know this means enterprise users and main-stream (non insider-track) users will be stuck without this functionality (obviously available in unix land for decades) for a while yet, but I'd rather MS rolled this out in a responsible manner rather than just open the flood-gates of potential malware. Symlinks may be basic, but they have been the cause of many nasty vulnerabilities in Linux over the years. Hopefully MS is just being cautious and in a year or so all Windows users will be able to create symlinks without any admin interjection at all.

Reply on news.ycombinator.com