Creating a separate Wine user account

[Daniel-I]

First a bit of background: I’ve been having a great transition to Linux experience the past 1-2 weeks, largely in part to the helpful people on these forums, lots of great applications in PAMAC/AUR, and Steam for providing Proton (which I understand leverages Wine)… and while Proton created a rather long/complex nesting of folders (per application/game) I needed to dig through to place/import my saved game/application files and information, I could see the logic in separating them and them not using/accessing my core Home folder.

One application that was working well on Steam was YNAB… my favorite budgeting software… that is, until I tried importing a OFX file from my bank to reconcile. In a perfect world, you would select “open with YNAB” while downloading a bank file, but YNAB (steam) was not in the list… so then I thought, no problem, I’ll download the OFX file then import it manually into YNAB, and the application crashed the moment you selected to import and requested the dialogue box to navigate to the file you wanted.

This may mean there could be some Steam/Proton configuring that I could do… but then I learned that I could install YNAB from the AUR repositories… but what I didn’t fully understand beforehand (was probably too excited and happily clicked next/next/next) was that wine was also a dependency that got installed at the same time. I knew something was up when I noticed I had more folders duplicated listed under my /Home/Documents folder (Pictures, Music, etc)… and I think in a context menu, I noticed Notepad (wine) was an option. I figured out I could unwind the folder mess by remapping the drives in winecfg, but immediately saw it had access to my /home folder.

My current issue/predicament: Fabby has been a great source of information, providing lots to digest as I make my transition to Linux. One of the [How To] links shared had another link to another [How To] which contained another link to “If you are using wine, make sure you setup a separate user account with minimal privileges”

So I read the specific subset of instructions and hope that someone can help this N00b out in understanding what some of the steps are asking me to do and what the consequences are:

1. If I were to complete these instructions, does that mean all the context and menu entries related to Wine should be removed/ignored as well, and purely run apps (including wincfg) via the scripts?
2. the note immediately after the first step says… “Now switch to another TTY”… what’s a TTY, how/when did I get to the first TTY, and what do I need to do to launch another TTY?
3. Right after the TTY reference, it mentions “The following approach only works when enabling root for Xorg”… wanting to make sure I meet this requirement I noticed the next command used xhost (which I assumed falls under Xorg) and when I ran sudo xhost if got a response, so I think I meet this requirement under Manjaro KDE Plasma…

sudo xhost
access control enabled, only authorized clients can connect
LOCAL:

4. Near the end of the instructions it mentions a step to "not be asked for a password each time Wine is run as another user "… does this imply that the first instruction to create the wine_account created the user with no password?
5. Will I still have access to the /home/wineuser folder? I hope so, because I’d need to move my YNAB files there! (and add them to my backup)

If there is a Manjaro KDE version of the instructions for N00bs, I’d definitely appreciate knowing about it!

Thank You!

[Aragorn]

@Daniel-I

If I were to complete these instructions, does that mean all the context and menu entries related to Wine should be removed/ignored as well, and purely run apps (including wincfg) via the scripts?

No, those instructions simply help you create an additional user account that you would then use with Wine.

The idea is that you log into that account instead of logging into your regular account, although it is also possible to start applications as another user account from within your regular account if you have the credentials of said other user account. But in that case, you would have to set up a number of launchers for those particular applications and configure them to run under the UID of the other user account.

@Daniel-I

the note immediately after the first step says… “Now switch to another TTY”… what’s a TTY, how/when did I get to the first TTY, and what do I need to do to launch another TTY?

UNIX (and by consequence, GNU/Linux) is a multiuser operating system. When the system boots, it initializes a number of ttys, i.e. login consoles. On desktop systems, one of those ttys will by default be configured to run a display manager ─ i.e. your graphical login screen ─ while the other ttys are normally character-mode-only. A tty is also often referred to as a virtual console.

Which tty the graphical session is shown at depends on the graphical user interface. In Arch and Manjaro with KDE Plasma, Plasma itself and the sddm display manager run at /dev/tty1.

In order to switch to /dev/tty2, just press Ctrl+Alt+F2. It is not necessary to log out of Plasma in order to do this. Your Plasma session will keep on running in the background, and you will now be looking at a character-mode virtual console with a text-mode login prompt.

In order to switch back to the Plasma session, you press Alt+F1, although just as switching to /dev/tty2 did not terminate your Plasma session, switching back to Plasma will not terminate your login shell at /dev/tty2. You exit the shell by either typing the command…

exit

… or by pressing Ctrl+D, which sends an “end of transmission” (EOT) character to the terminal and logs you out.

@Daniel-I

Right after the TTY reference, it mentions “The following approach only works when enabling root for Xorg”… wanting to make sure I meet this requirement I noticed the next command used xhost (which I assumed falls under Xorg) and when I ran sudo xhost if got a response, so I think I meet this requirement under Manjaro KDE Plasma…

Manjaro enables this by default.

@Daniel-I

Near the end of the instructions it mentions a step to "not be asked for a password each time Wine is run as another user "… does this imply that the first instruction to create the wine_account created the user with no password?

An account without a password cannot log in. Every login account must have a password, although the password can be blank ─ which is not the same thing as not having a password, and which is highly recommended against for security reasons. However, ways do exist for elevating the privileges of user accounts so that they can execute commands as another user without needing to enter a password.

Note: This would of course have to be set up by the root account. Normal user accounts cannot elevate their own privileges.

@Daniel-I

Will I still have access to the /home/wineuser folder? I hope so, because I’d need to move my YNAB files there! (and add them to my backup)

That depends on what permissions you set on that directory, and which umask you set up for the wineuser account.

[Daniel-I]

@Aragorn

No, those instructions simply help you create an additional user account that you would then use with Wine.

The idea is that you log into that account instead of logging into your regular account…

I see, so I could do a “switch user”, do what I needed in wine/YNAB, then switch back.

So one thing is unclear. When I installed YNAB (which installed wine), was that an install specific to my user account or system-wide? I’m hoping/assuming that for wine to be restricted to a specific user that the install was user specific… which would also mean that part of my steps should really include uninstalling wine/YNAB under my account and reinstalling them under the wineuser account?

[Aragorn]

@Daniel-I

I see, so I could do a “switch user”, do what I needed in wine/YNAB, then switch back.

That, or you can set up the launchers to run that specific application as the other user.

@Daniel-I

When I installed YNAB (which installed wine), was that an install specific to my user account or system-wide?

I don’t know for certain, because I don’t use Wine or Windows. But if it was installed via wine, then it may be possible that it was local to your user account.

As I understand it, Wine emultates the Windows concept of drive letters, and will thus load its applications by way of those emulated drive letters. It should therefore be easy enough for you to figure out where the executable for that Windows program is installed.

@Daniel-I

I’m hoping/assuming that for wine to be restricted to a specific user that the install was user specific… which would also mean that part of my steps should really include uninstalling wine/YNAB under my account and reinstalling them under the wineuser account?

If that is the case, then yes.

However, you have to bear in mind that Wine is only a translation layer to allow Windows applications to run on UNIX. Ergo, Wine is not an emulation of a complete Windows system and does not implement the Windows model of multiple user accounts. It leaves the handling of user accounts and their access rights to the underlying UNIX system.

[Daniel-I]

I’m getting the impression that by creating the wineuser account, what I’m really accomplishing is more like a “sandbox” approach that I choose to use. I’m not really hardening the system “against” wine, or forcing every wine app call through the wineuser, as wine is installed and able to be used under my (or any other) user account… which is someways makes me feel that this method doesn’t really protect the system at a “core level” at all.

But this may be where my understanding of Linux is evolving. If, for example, one could say that Linux is very secure up to the point where the user takes an action (i.e. downloads and executes a file)… then choosing how/when/where one executes something is more of a good safety habit. (Hmm, I guess one could say that about every OS) Like making sure the firewall is enabled, using firetools/firejail, and ClamAV. Default to deny, not to trust.

And then there could also be a misunderstanding of wine too… perhaps it is not always running in the background and presenting an ongoing security threat waiting to happen… maybe it’s only an issue when something is executed that needs wine and wine jumps into action to help it out. So then if I intervene (manually or via script) to control my wine calls/apps… it’s a more limited/safer use of wine if the concern is that the application it is supporting is not known to carry a payload or not.

I guess the lingering thought is… what if something else springs wine into action that wasn’t me? Is that possible, or would that imply that I already executed something with a payload that infected me by not following the “safety rules”… and it used wine to it’s advantage?

Oh no… I’m caught in a loop!

[Aragorn]

@Daniel-I

And then there could also be a misunderstanding of wine too… perhaps it is not always running in the background and presenting an ongoing security threat waiting to happen…

It isn’t. It’s not a service. It’s a wrapper around Windows applications, and these Windows applications must be started through Wine ─ it does not suddenly try to automatically run every Windows application that you would attempt to start without invoking Wine.

Think of it this way… If you attempt to start a GUI application from a command-line tty, then you’re going to get an error message because the $DISPLAY variable isn’t set. Likewise, if you’re going to try starting a Windows application by typing its name at a command prompt without invoking Wine, then you’re going to get an error message that it’s not an ELF executable.

@Daniel-I

I guess the lingering thought is… what if something else springs wine into action that wasn’t me? Is that possible, or would that imply that I already executed something with a payload that infected me by not following the “safety rules”… and it used wine to it’s advantage?

If you execute a Windows binary through Wine and the binary contains malware, then this malware can infect other files in your home directory, but it would still only be Windows malware and it would also only be able to access files that your user account has write access to. It would not be able to infect files owned by any other account in the system, nor any root-owned system files.

[Daniel-I]

Okay, I think it’s starting to sink in… Looking back at the instructions there really is only one core “configuration” command… make that restricted/standard wineuser account, which I feel I could do by…

1. the wiki’s command line instruction… # useradd -m -s /bin/bash wineuser
2. or I imagine I could use the GUI “user account” tools to create the user as well (I noticed when I created a test user that a new folder was created under /home (-m) and that the /etc/defaults/adduser settings show the same shell (-s /bin/bash/)

$ sudo cat /etc/default/useradd
# useradd defaults file for ArchLinux
# original changes by TomK
GROUP=users
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no

The lines that immediately follow the user creation are setting the stage/background for the scripting to run things as the wineuser within my session/login.

1. $ xhost +SI:localuser:wineuser allows the wineuser user to access the running X server (which I am guessing is my GUI session)
2. $ sudo -u wineuser env HOME=/home/wineuser USER=wineuser USERNAME=wineuser LOGNAME=wineuser wine arguments fires up the app as the wineuser

And scripting could be replaced by switching users, but I see how that could be a pain too.

I’m thinking under my usecase, which is currently to only ever execute YNAB via wine, which I’ve known and used for years… I think I’ll call myself “safe” only because I trust it as an application. But will of course keep all of this topics discussion in my back pocket in case I ever find a need to install more wine apps… which I will consciously try avoid/mitigate.

And while the end of the instructions talk about setting up the winecfg for the wineuser, I also think there should be some winecfg adjustments under my account too if I find myself using wine more… like potentially playing with/removing:

• file associations
• disabling mappings to my home folder/subfolders

There is one assumption here though… that AUR (where I found/installed YNAB from, with wine as a dependency) is a trusted/clean source. Is AUR as a source I can trust to have installed YNAB from? Because if it’s not, then I can see the need to use the restricted account… although maybe it’s too late to think about that as I’ve installed and used YNAB from AUR already.

[Aragorn]

@Daniel-I

Is AUR as a source I can trust to have installed YNAB from?

In general, the AUR can be trusted, but there is no guarantee that there will never be a compromised package on there.

As the matter of fact, the packages are themselves not stored on the AUR. All that is there for each AUR package is a PKGBUILD, which is a script that pulls in the necessary files from where they are stored, and the instructions to build the binary on your system if necessary. But the good news is that the PKGBUILD is a human-readable file, so you can check what it is pulling in and from where.

There have in the past been compromised contributions to the AUR, but this is usually quickly discovered, and then the uploader’s account gets deleted. So in general it’s considered safe, but it’s always best to inspect the PKGBUILD.

[Daniel-I]

Thank you Aragorn for all your patience and guidance!

Reading How to inspect AUR package PKBUILD and .install files / Newbie Corner / Arch Linux Forums now so that I can check the YNAB PKBUILD.

Calling this thread solved!

[Aragorn]

@Daniel-I

Calling this thread solved!

Would you then please mark the post that solved it? That way, a link to the solution will be added to the opening post.

[Daniel-I]

It was hard to pick just one post as the solution really was cumulative

I also thought I was going to have to go digging for the PKGBUILD files… but found they are readily available in “Add/Remove Software” (PAMAC?) by clicking the Build files button (here I thought it was an action )

I think that’s great that the inspection can be proactive!

Had I known in advance it was just using wine to launch the installer/EXE, I could have provided my own file (but that would have involved learning more about wine upfront)… so in this case its more a question about the trustworthiness of “https://web.archive.org” that appears to be caching an old copy of the once official “https://classic.youneedabudget.com”.

[Daniel-I]

To save myself some wine learning curve, I decided two things to be true:

1. I trust my YNAB install/setup file I’ve had for years… and…
2. I trust my existing (windows) installed YNAB application files installed by my installer that I’ve used for years

So I thought I’d try compare things to get to a place “I trust” because I really wasn’t all that excited about learning “https://web.archive.org” was the source for the YNAB setup file…

1. I found I could use rsync to build a patch file as a form of compare between 2 large binary files… and an 18Kb patch file was built when it compared the two 20.2Mb files… rsync --only-write-batch=ynab-diff Setup.exe YNAB_4_4.3.857_Setup.exe so obviously they are close, but not exactly the same (Setup.exe being what was pulled down as part of the PKGBUILD)
2. So I mounted my windows disk and eye-balled the file structures my old YNAB install had written there and the files/folders appeared to be identical structurally other than a 1 hour time difference to the modified timestamps of a few files.
   
   

So I decided to try copy the windows installed “YNAB 4” file structure (that I trust) from my windows drive to the /home/<user>/.ynab4/wine/drive_c/Program Files (x86)/ path created during the AUR deployment (after first renaming the AUR installed folder to “YNAB 4.AUR”)… and YNAB continues to work beautifully under wine…

Perhaps a little unconventional, and perhaps a little bit like “cheating” (deferring to learn to use wine to deploy my installer; hopefully don’t need to if YNAB remains my only wine run app)… but I’m now in a position where I trust the binaries in place as they are exactly what I’ve used and trusted previously under windows.

And more importantly, I now know to pay attention to PKGBUILD when installing things from AUR.