#Issues with Trivalent when home directory is on a separate disk

1 messages · Page 1 of 1 (latest)

minor trench
#

I want my user's home directory to be on a separate disk than the OS installation. I have it set to /mnt/ssd-1/user.

With it configured like this, trivalent fails to launch at all.

Okay, so I need to do ujust label-external-drives to give trivalent access to it. Though it already is my home directory, I don't see why this would be necessary. I took the script and slightly modified it because my drive isn't mounted under /run/media/user since It's supposed to be a cross system drive, not just for user. For this reason, I also didn't have it label the whole drive, but just a directory inside it.

Now with this update, trivalent can launch and be used pretty well. It still complains a bit about some missing permissions on directories that are tagged with user_home_t. The biggest issue is when browsing a site (and generally only after I start typing into that site) it will crash within a few seconds because of SIGILL.

What could be done next to get it back to working order?

#

here is the current output from running trivalent in the terminal, all the way up until a site crashes

📎 log.txt
minor trench
#

So I stumbled into trivalent.fc noticed the last two lines:

HOME_DIR/\.cache/trivalent(/.*)?        gen_context(system_u:object_r:trivalent_home_t,s0)
HOME_DIR/\.config/trivalent(/.*)?    gen_context(system_u:object_r:trivalent_home_t,s0)

I figured if I could get these commands to run then I would be in the clear. I peaked at the script for label-external-drives again and took the line:

run0 sh -c "semanage fcontext -a -t $selabel '$dir(/.*)?' && restorecon -r '$dir'"

Modified it and ran it for both the ~/.config/trivalent and ~/.cache/trivalent directories:

run0 sh -c "semanage fcontext -a -t trivalent_home_t '$HOME/.config/trivalent(/.*)?' && restorecon -r '$HOME/.config/trivalent'"
run0 sh -c "semanage fcontext -a -t trivalent_home_t '$HOME/.cache/trivalent(/.*)?' && restorecon -r '$HOME/.cache/trivalent'"

After this trivalent seems to be working perfectly. I'm currently typing this out on trivalent, which is great because it was hardly possible to type a few words before a site would crash!

kind trail
#

-# just a guess: the existing policy in trivalent.fc looks good, but ujust label-external-drives isn't intended to label things as user_home_t when they're actually already the user's home directory - that should be done automatically. instead, couldn't you have just used restorecon -R on the new home directory, and remove all the semanage modifications?

#

-# it just seems that label-external-drives screwed things up by overriding the default .fc policy and labelling your /mnt homedir contents as user_home_t, and from now on you're going to have to keep manually labelling the rest of your homedir if you don't fix it

#

-# yeah that seems right, maybe try semanage fcontext -l -C, and fix each one with semanage fcontext -d? then restorecon -R /mnt/ssd-1/user

#

also, is there any reason you're not mounting your storage directly to /home/youruser?

#

that might be less confusing

minor trench
kind trail
kind trail
# 
# chown -R user:user /mnt/ssd-1/user
# mount --bind /mnt/ssd-1/user /var/home/user
# semanage fcontext -l -C   # list all manual file context overrides
# semanage fcontext -D   # after review, undo all these
# restorecon -R -F /var/home/user   # force relabel your homedir

and obviously in /etc/passwd, make sure your user line is like

user:x:1000:1000::/var/home/user:/bin/bash

you can then check the types are set right:

$ ls -Z ~/.config/trivalent
$ ls -Z ~/.cache/trivalent
$ ls -Z ~/.ssh    # for good measure, should be ssh_home_t, which may be broken for you rn
kind trail
#

oh also if you're using a bind mount, you'll need to add it to /etc/fstab:

/mnt/ssd-1/user /var/home/user none bind,nofail,x-systemd.requires-mounts-for=/mnt/ssd-1/user 0 0
minor trench
minor trench
minor trench
#

ah it has to require mount for /var/mnt/... not just /mnt/...