Using encryption on my system level files repository makes my system fail to boot.

[rizzini]

I didn't troubleshoot that yet. I came here first if someone managed to work around that.

I keep track of my system files with the tip given by @TheLocehiliosan itself here. You guys can see at my Dotfiles.system repository it works just fine.

[TheLocehiliosan]

Can you explain what you mean by "using encryption on my system level files"? What commands did you run before your problem?

I looked at your repo and I don't see any yadm encrypt or archive file within the repo, so it is hard to tell what you might have been trying to do.

[rizzini]

Can you explain what you mean by "using encryption on my system level files"? What commands did you run before your problem?

I have two repositories on my system. One for my home dotfiles and another for my system-wide dotfiles, right? I successfully use encryption on my home repository, so I can keep track of some sensitive files, but I can't do the same on my system-wide repository. If I create the encrypt file and then run sudo yadm -Y /etc/yadm encrypt, my system won't boot anymore. I'll create a BTRFS snapshot and reproduce this now to try to find something. It seems you need more information.

The commands I ran before? I don't remember, I set up the repositories months ago. What I can say is that a while ago I saw your tip, created a local git repository, added the system-wide files I want to keep track and since then I'm constantly pushing the local changes to Github. You didn't find the encrypt or the archive files, because I deleted them a while ago because of that behavior.

[rizzini]

I tried again now and, for some reason, it worked. Go figure.. Maybe some change in the recent version could have been fixed this or I may messed it up real bad then, but I don't remember doing anything different from what I did then. Anyway, closing the issue..

Many thanks for your work!!!

[rizzini]

My bad, the issue is still happening. The system boots, but I can't log in with my account. I end up at TTY. Recently I had to reinstall the whole system and the issue happened in the new installation as well.

I did nothing special:

1. Created the /etc/yadm/encrypt file with the files I want to encrypt.
2. Ran sudo yadm -Y /etc/yadm encrypt, which creates the /root/.local/share/yadm/archive file.
3. Then sudo yadm -Y /etc/yadm push

The local repository is located at /root/.local/share/yadm/repo.git/.

No wonder I cant log in.. For some reason, my user isn't recognized anymore. Its id, 1000, is associated to nothing. I'm encrypting some pretty sensitive files related to users, but I don't know how or why yadm is messing with them, since, as far as I know, it just encrypts them.

Sorry for the confusion.

[TheLocehiliosan]

I just tried doing this on a VM, and I didn't encounter any of the files being changed (using the same encrypt file as you).

The encrypt process works by taring up all of the files (which merely reads the files) and then piping that archive into a gpg (or other encryption if specified). I can't see how that should effect any of the files being archived.

Can you offer any other details? or maybe an explicit set of steps that reproduce a problem?

[rizzini]

Can you offer any other details? or maybe an explicit set of steps that reproduce a problem?

Now I could narrow it down a bit. I can't boot when I encrypt these files below. I didn't test all of them one by one. Before I thought that by just enabling encryption I wasn't enabled to boot anymore, which now I know it's not the case.

etc/shadow
etc/shadow-
etc/passwd
etc/passwd-
etc/gshadow
etc/gshadow-
etc/group
etc/group-

I captured my entire failed boot logs with journcalctl --boot=0 -> https://pastebin.com/4Bx0CB66

These lines drew my attention:

mar 12 19:49:36 archlinux dbus-daemon[690]: dbus[690]: Could not get password database information for UID of current process: User "???" unknown or no memory to allocate password entry
...
mar 12 19:49:35 archlinux systemd[606]: Starting D-Bus User Message Bus...
mar 12 19:49:35 archlinux systemd[606]: dbus.service: Main process exited, code=exited, status=1/FAILURE
mar 12 19:49:35 archlinux systemd[606]: dbus.service: Failed with result 'exit-code'.
mar 12 19:49:35 archlinux systemd[606]: Failed to start D-Bus User Message Bus.

It seems the reason my X can't come up, but interestingly enough, I can log in at TTY. Usually, troubleshooting isn't a major pain to me, but I have no idea what's going on here.

I use BTRFS, so I can do any test you want.

[rizzini]

@TheLocehiliosan, it seems YADM is messing with my files permissions. It makes sense since keeping track of system-wide files it's not an officially supported solution.

Example:

/etc/yadm/encrypt:

etc/sudoers
etc/security/*
etc/security/limits.d/*

ls /etc/security/ before encrypting the files:

 ╭─lucas@archlinux em ~ 
 ╰─λ ls /etc/security/
drwx------    - root  6 mar 16:42  limits.d
.rw-r--r-- 4,6k root  8 set  2021  access.conf
.rw-r--r-- 2,2k root  8 set  2021  faillock.conf
.rw-r--r-- 3,6k root  8 set  2021  group.conf
.rw-r--r-- 2,4k root  8 set  2021  limits.conf
.rw-r--r-- 1,6k root  8 set  2021  namespace.conf
.rwxr-xr-x 1,0k root  8 set  2021  namespace.init
.rw-r--r-- 3,0k root  8 set  2021  pam_env.conf
.rw-r--r-- 2,2k root  8 set  2021  time.conf

ls /etc/security/ after encrypting the files:

 ╭─lucas@archlinux em ~ 
 ╰─λ ls /etc/security/
drwx------    - root  6 mar 16:42  limits.d
.rw------- 4,6k root  8 set  2021  access.conf
.rw------- 2,2k root  8 set  2021  faillock.conf
.rw------- 3,6k root  8 set  2021  group.conf
.rw------- 2,4k root  8 set  2021  limits.conf
.rw------- 1,6k root  8 set  2021  namespace.conf
.rwx------ 1,0k root  8 set  2021  namespace.init
.rw------- 3,0k root  8 set  2021  pam_env.conf
.rw------- 2,2k root  8 set  2021  time.conf

[TheLocehiliosan]

Ok. This is making sense to me now.

You can change this behavior with the "yadm.auto-perms" configuration.

https://github.com/TheLocehiliosan/yadm/blob/master/yadm.md#permissions

When doing a decrypt, you might need to do some fix up of the permissions yourself, as they will default to whatever your unmask defines.

[rizzini]

Right on!! Sorry if it took me some time to understand what was really going on my side. Thank you, man! Now I'll feel much, much safer.

When doing a decrypt, you might need to do some fix up of the permissions yourself, as they will default to whatever your unmask defines.

I only decrypt if I'm setting up a new installation anyway. I go almost file by file so no problem there.