Kerberos, automatic user

[ehartford]

• A brief description

I want the WSL to automatically make a unix user for my windows user, (kerberos) and I want it to automatically log me in as that user unless I specify otherwise.

I want my WSL home directory to be my Windows user home directory (just like cygwin, mingw)

So I can share my ~/.ssh/config and ~/.vimrc etc

I just don't want to be exposed to the idea that "WSL has separate users" unless I want to be.

[sunilmut]

@ehartford - Good ideas and thanks for the feedback. We appreciate it. Because, there is more feature requests than the bandwidth, we have to prioritize the work for the future. We do that by looking at our user voice page. Please head out there and open a new ticket (if there is not one already) for this and when it reaches critical mass (of votes), it will be hard to resist for us. And, please keep the feedback coming.

[thorsteneb]

I want my WSL home directory to be my Windows user home directory (just like cygwin, mingw)

I'm not sure how awesome that would be. The Windows file system is handled less "Linuxy" than the WSL file system, see https://msdn.microsoft.com/en-us/commandline/wsl/faq

As a result, building from source from within /mnt/* is bound to fail, where it works in ~/ or /var/tmp. Sure, I could stop working in ~/, but I actually like being able to use, say, rakudobrew in there.

[therealkenc]

NTFS is a little more Linuxy now that Microsoft has come to a point of acceptance (after 20 years) that symlinks are a thing. I'm holding out hope this continues to improve; especially if the intent here is to pry the MacBooks out of millennial developers' cold dead hands. By 2037 Microsoft may even come to accept that unlinking file objects with open handles is also a thing.

[fpqc]

@therealkenc Do they have a reason for keeping that behavior (locking files with open handles)?

I remember in the bad old days of Win7 I had to use a tool called unlocker to find what processes had open handles on files when they wouldn't clear properly. It was mostly a hindrance. I've had fewer problems nowadays with Win10 thankfully, but it would be nice to be able to unlink as you say.

[thorsteneb]

@therealkenc Sure, we have symlinks now. Having two files that differ only in case is not supported on NTFS, and I don't see it happening. Chown and chmod raise real questions, because that's not how NTFS works. NTFS has ACLs while *ix has always maintained that owner/group/everyone is good enough for any use case.

Seeing the additional complexity with very little gain, I'd really rather have my Ubuntu ~/ on VolFS, not FileFS, the way it is now.

You say you want .ssh and .vimrc to travel. Any reason you couldn't designate the copy on /mnt your master copy, have a few lines in .bashrc that copy them over (*), and only ever make changes to the files in /mnt?

(*) If you want to use the same .bashrc in both environments, you can detect WSL by looking at /proc/version.

[aseering]

@yorickdowne :

• NTFS does support having two files that differ only in case. It's disabled by default, I imagine because it breaks a lot of software whose developers were not careful to refer to their files using the same case consistency, so you're probably right that it won't become the default.

• Linux supports ACLs too these days, though it's true that they're not always enabled by default. (I typically do enable them on any multi-user system that I set up because they're so useful.) chmod and chown have well-defined behavior in terms of those ACLs. Admittedly, Linux and Windows ACLs don't have exactly the same semantics; they could probably be mapped in a way that's useful but not exact.

[thorsteneb]

@aseering Thanks! Always good to learn new things. My main point remains though: What a pain to deal with all that when the goal is just to not have two copies of .ssh. Syncing that directory by whichever means seems so much simpler.

[ehartford]

that's not the goal... It's having one profile, the .ssh was just an example. also not having to worry about multiple users, unless that's actually something I care about. Look, it's Windows not Linux. There are expectations. Things should "Just Work" without fiddling.

[thorsteneb]

@ehartford I'll be that guy who says "we'll have to agree to disagree".

I want the WSL to automatically make a unix user for my windows user, (kerberos) and I want it to automatically log me in as that user unless I specify otherwise.

It kinda does that now. Minus the sudo password, noted. I'm not sure how to get around that short of having WSL use the same kind of hash that Windows uses. I'm not sure how Linux-y that would be. Clearly Windows doesn't have my plain text password, so it can't re-hash it for WSL without my entering it. I do want sudo, that's integral to how Linux behaves.

I want my WSL home directory to be my Windows user home directory (just like cygwin, mingw)

We've discussed that. For all the reasons already given, please no. I LIKE that I can build Linux stuff from source. I like that I can use Linux binaries and expect them to work. And that is made so much easier by ~/ being VolFS.

Look, it's Windows not Linux. There are expectations. Things should "Just Work" without fiddling.

That sounds reasonable yet:

• WSL is a dev environment. Isn't fiddling what devs do? Of course I don't want to fiddle more than necessary, I'm all for WSL getting better at being Linux-like. Which brings me to:
• WSL is a dev environment specifically designed to look and feel as much like Linux as possible, for devs that code with a Linux target for one. It's Bash on Ubuntu on Windows. I want it to behave as much as Ubuntu on Linux as possible. Whaddaya mean "it's not Linux"? I mean sure, no Linux kernel as such, but it should behave as much like Linux as the WSL dev team can make it.

If you're not using it for dev, maybe Powershell would be a better option?

[aseering]

Linux supports plugfable authentication these days. Someone (doesn't really even need to be someone at Microsoft) could write a PAM module that passes the raw username and password to Windows for validation.

For what it's worth, I think I do personally favor using users' Windows home directories as their Linux home directories as a long-term plan. The status quo has been the source of all kinds of confusion, often from devs who want to use Windows and Linux tools simultaneously. But not today. As noted, too many things would break if the switch were made right now.

[therealkenc]

Turns out (as with most things WSL) someone already has for native. It would probably need some adaptation to feel at home on Windows, and I haven't made the effort to work up a demo yet though.

[jouhoff]

Quiet late, still I used to Auto-it things like this. Reduced reliance on more third party solutions and you got a grip on it yourself.

Tldr, Power-automate is amazing for small glue handcrafts.

Cheers!

[TheJayMann]

Something I've just tried that appears to work, though more of a workaround than a solution, is making use of the ms2mit utility available in MIT's Kerberos for Windows distribution. By specifying -c ccache (in my case, I just did -c FILE:ccache), then specifying within WSL the environment variable KRB5CCNAME to use the same file, I was able to make use of GSS-API in WSL using the tickets already created in Windows. The only testing I've done was using curl against an Azure DevOps Server, which worked without issue.

Edit: I've further tested LibreWolf (FireFox) as an app image, setting up negotiate auth trusted uris, and it also worked properly when loading the Azure DevOps Server home page, as well as other websites using Windows Integrated Authentication.