systemd-homed.service is a service included with systemd which promises a better way of handling /var/home user directories…
The user-facing command to use it is homectl
It supports LUKS-encrypted home directories (individual encryption per-user) which can’t be circumvented by just running as root.
It supports traditional directories too… if individual encryption isn’t for you…
It stores all the user-metadata in ~/.identity rather than /etc/{passwd,shadow,group,gshadow}, in the JSON format.
The home directory (or LUKS image file) is portable across different systems, but unfortunately this is just in theory for now; Requiring a few more hacks etc.. for actually moving/copying a homedir to another system.
Can I use it? IK that some SELinux issues persisted… I can rpm-ostree usroverlay and fix the issues manually, but still, is the issue still there?
Is anyone interested in this systemd-homed concept?
I have a home directory I use on 2 laptops and one desktop, which work great. Things to take note on:
You have to copy the public key where you created the home user to the system you want to migrate to for login. To successfully change home records on any system, you need both private and public keys. I store both on my encrypted home directory for additional portability.
UID’s change from system to system.
Podman creates it’s files dependant on UID. So containers,etc. won’t migrate as expected. There are workarounds.
User flatpaks work as they should.
Login avatars don’t work yet, but is being worked on.
After creating your home user, you should relabel the home directory to assure normal operations.
Selinux issues should be resolved for normal uses. If you find any please report them. In general I think it’s a great concept and option to have.
The one drawback to true portability…
richiedaze:
UID’s change from system to system.
Podman creates it’s files dependant on UID. So containers,etc. won’t migrate as expected. There are workarounds.
Can’t I manually assign the UID? Like via --uid flag to homectl?chown things? No chmod so mode is intact…
Expected;
Some things are better handled by systemd-userdbd state directories etc… rather than random places under $HOME… but who listens?
There’s already a solution for that, if anyone is willing to follow: User Record Blob Directories
Huh! Some help plz..
I didn’t understand; IDK SELinux
Of course…
BTW, my /var/home will a bcache i.e. HDD cached by SSD…ext4 for it; LUKS-encrypted systemd-homed volumes will use btrfs.
Do you any other suggestions other than ext4?
opened 06:41PM - 24 Jun 24 UTC
bug 🐛
needs-reporter-feedback ❓
homed
### systemd version the issue has been seen with
255
### Used distribution
Fe… dora 40
### Linux kernel version used
kernel-6.9.5-200.fc40.x86_64
### CPU architectures issue was seen on
x86_64
### Component
homectl
### Expected behaviour you didn't see
Portable homed's uid to be respected on other systems.
### Unexpected behaviour you saw
homed assigns a new uid in it's bindings neglecting it's original even though it's available in the new system.
### Steps to reproduce the problem
* Migrate user.public key to the new system, then login.
* Migrate both signing keys to the new system, then login.
Both have the same results
<details>
<summary>
~/.identity
</summary>
```
administrator@fedora:~$ cat ~/.identity
{
"autoResizeMode" : "off",
"disposition" : "regular",
"enforcePasswordPolicy" : false,
"lastChangeUSec" : 1717037492043162,
"lastPasswordChangeUSec" : 1698125233860107,
"luksDiscard" : false,
"luksExtraMountOptions" : "defcontext=system_u:object_r:user_home_dir_t:s0",
"perMachine" : [
{
"fileSystemType" : "btrfs",
"imagePath" : "/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_04012013e0a2bf3dc677771688f40d65c41c75c78d3f4a7f7ed4423a3b530b8b7b2c00000000000000000000c68a13caff1f6b1883558107442ccac3-0:0",
"matchMachineId" : "f835684c4b084af6a35a9ffababf90bc",
"skeletonDirectory" : "/var/home/administrator/.config/skel",
"storage" : "luks"
}
],
"privileged" : {
"hashedPassword" : [
"$y$j9T$tuA8VrLq74YNpGFjeuLmU.$duyg6mVPICZxzGOwoIhV7xXQdTsfsQZ6TZthkyawNRB"
]
},
"signature" : [
{
"data" : "wCQQ/tbf9IpTZkf/I3uAZXpNumJV4jDVwhZVd/RqdvndGb7e9y4hhwe3b22qodkub4D/TNwFWe86pf2jlskpBg==",
"key" : "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAz5JqLH9965jX2BZm/WNSgsN6n2cqmHG2qy5fXVB80pc=\n-----END PUBLIC KEY-----\n"
}
],
"uid" : 60001,
"userName" : "richiedaze"
}
```
</details>
<details>
<summary>
/var/lib/systemd/home/richiedaze.identity
</summary>
```
administrator@fedora:~$ sudo cat /var/lib/systemd/home/richiedaze.identity
{
"autoResizeMode" : "off",
"binding" : {
"3f45aad25d714ce0ac730bac550a3c9e" : {
"fileSystemType" : "btrfs",
"fileSystemUuid" : "80b88d1f-1d51-4f1d-9640-b16343264ae7",
"gid" : 60056,
"homeDirectory" : "/home/richiedaze",
"imagePath" : "/dev/disk/by-uuid/9117c6c6-2ffe-4cdc-8dc8-0b73346f26ab",
"luksCipher" : "aes",
"luksCipherMode" : "xts-plain64",
"luksUuid" : "9117c6c6-2ffe-4cdc-8dc8-0b73346f26ab",
"luksVolumeKeySize" : 32,
"storage" : "luks",
"uid" : 60056
}
},
"disposition" : "regular",
"enforcePasswordPolicy" : false,
"lastChangeUSec" : 1717037492043162,
"lastPasswordChangeUSec" : 1698125233860107,
"luksDiscard" : false,
"luksExtraMountOptions" : "defcontext=system_u:object_r:user_home_dir_t:s0",
"perMachine" : [
{
"fileSystemType" : "btrfs",
"imagePath" : "/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_04012013e0a2bf3dc677771688f40d65c41c75c78d3f4a7f7ed4423a3b530b8b7b2c00000000000000000000c68a13caff1f6b1883558107442ccac3-0:0",
"matchMachineId" : "f835684c4b084af6a35a9ffababf90bc",
"skeletonDirectory" : "/var/home/administrator/.config/skel",
"storage" : "luks"
}
],
"privileged" : {
"hashedPassword" : [
"$y$j9T$tuA8VrLq74YNpGFjeuLmU.$duyg6mVPICZxzGOwoIhV7xXQdTsfsQZ6TZthkyawNRB"
]
},
"signature" : [
{
"data" : "wCQQ/tbf9IpTZkf/I3uAZXpNumJV4jDVwhZVd/RqdvndGb7e9y4hhwe3b22qodkub4D/TNwFWe86pf2jlskpBg==",
"key" : "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAz5JqLH9965jX2BZm/WNSgsN6n2cqmHG2qy5fXVB80pc=\n-----END PUBLIC KEY-----\n"
}
],
"status" : {
"3f45aad25d714ce0ac730bac550a3c9e" : {
"goodAuthenticationCounter" : 2,
"lastGoodAuthenticationUSec" : 1719212008574595,
"rateLimitBeginUSec" : 1719212007316529,
"rateLimitCount" : 1
}
},
"uid" : 60001,
"userName" : "richiedaze"
}
```
</details>
Removing /var/lib/systemd/home/richiedaze.identity as suggested [here](https://github.com/systemd/systemd/issues/28982#issuecomment-1697257680) does not make a difference.
```
administrator@fedora:~$ homectl
NAME UID GID STATE REALNAME HOME SHELL
richiedaze 60056 60056 unfixated richiedaze /home/richiedaze /bin/bash
```
Logging in to the original system where the home was created honors it's uid
### Additional program output to the terminal or log subsystem illustrating the issue
```sh
journalctl -b -u systemd-homed | grep ' Directory /home'
Jun 24 13:30:21 fedora systemd-homed[1012]: Directory /home is not on a real block device, not checking quota for UID use.
```
opened 02:10PM - 31 Aug 21 UTC
closed 10:17AM - 03 Apr 22 UTC
Good First Issue
kind/bug
stale-issue
volunteers-wanted
locked - please file new issue/PR
/kind bug
**Description**
I changed my user account's id from 1001 to 1000 o… n a system where I had already started using podman as that user.
After changing ids, all podman operations fail with `Error: error creating tmpdir: mkdir /run/user/1001: permission denied`.
**Steps to reproduce the issue:**
1. Create a user account
2. Use podman with this account to build images and run containers.
3. Change user and group id using `usermod -u <new-uid> <user> && usermod -g <new-gid> <group>`.
4. Reboot
5. Run podman and see permission error
**Describe the results you received:**
Podman fails trying to create a run directory for the wrong user id.
**Describe the results you expected:**
Podman works correctly with the new user id.
**Additional information you deem important (e.g. issue happens only occasionally):**
Root podman still works correctly on this machine. I'm unable to run even `podman version` as my user.
**Output of `podman version`:**
```
Version: 3.0.1
API Version: 3.0.0
Go Version: go1.16
Built: Thu Jan 1 05:30:00 1970
OS/Arch: linux/arm64
```
**Output of `podman info --debug`:**
```
host:
arch: arm64
buildahVersion: 1.19.6
cgroupManager: systemd
cgroupVersion: v1
conmon:
package: 'conmon: /usr/bin/conmon'
path: /usr/bin/conmon
version: 'conmon version 2.0.25, commit: unknown'
cpus: 4
distribution:
distribution: ubuntu
version: "21.04"
eventLogger: journald
hostname: wopr
idMappings:
gidmap: null
uidmap: null
kernel: 5.11.0-1016-raspi
linkmode: dynamic
memFree: 235421696
memTotal: 3974946816
ociRuntime:
name: runc
package: 'runc: /usr/sbin/runc'
path: /usr/sbin/runc
version: |-
runc version 1.0.0~rc95-0ubuntu1~21.04.2
spec: 1.0.2-dev
go: go1.16.2
libseccomp: 2.5.1
os: linux
remoteSocket:
exists: true
path: /run/podman/podman.sock
security:
apparmorEnabled: true
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
selinuxEnabled: false
slirp4netns:
executable: ""
package: ""
version: ""
swapFree: 4567515136
swapTotal: 4730044416
uptime: 26h 20m 5.21s (Approximately 1.08 days)
registries: {}
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 24
paused: 0
running: 21
stopped: 3
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/lib/containers/storage
graphStatus:
Backing Filesystem: btrfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 13
runRoot: /run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 3.0.0
Built: 0
BuiltTime: Thu Jan 1 05:30:00 1970
GitCommit: ""
GoVersion: go1.16
OsArch: linux/arm64
Version: 3.0.1
```
**Package info (e.g. output of `rpm -q podman` or `apt list podman`):**
```
Listing... Done
podman/hirsute,now 3.0.1+dfsg1-1ubuntu1 arm64 [installed]
```
**Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)**
Yes
**Additional environment details (AWS, VirtualBox, physical, etc.):**
Physical on a raspberry pi 4.
Pramod V. U.:
Some things are better handled by systemd-userdbd state directories etc… rather than random places under $HOME… but who listens?
There’s already a solution for that, if anyone is willing to follow: User Record Blob Directories
Systems Display Managers still need to implement the changes for it to work.
Pramod V. U.:
Huh! Some help plz..
New home directories created by homectl will not correctly label the home directory.
After creating you new home and logging in you should enter:restorecon -vR ${HOME}
This command should relabel your home directory so that it’s currently the same as creating a new home directory with commandline program like adduser or desktop equivalent.
Pramod V. U.:
Of course…
BTW, my /var/home will a bcache i.e. HDD cached by SSD…ext4 for it; LUKS-encrypted systemd-homed volumes will use btrfs.
Do you any other suggestions other than ext4?
That would depend on your uses.
The issues…
That’s what I meant.
Thanks,
Could you let me know of what you use on your system? For the backing /home and for the $HOME in the LUKS image?