feat: restore /etc/passwd shell paths on deactivation#377
feat: restore /etc/passwd shell paths on deactivation#377
Conversation
During deactivation, scan /etc/passwd for shells under /run/system-manager/sw/ and restore them to FHS paths. Shell restoration is best-effort: errors are logged but do not prevent deactivation from completing. This fixes #371
| } | ||
|
|
||
| let fields: Vec<&str> = line.split(':').collect(); | ||
| if fields.len() != 7 { |
There was a problem hiding this comment.
https://man7.org/linux/man-pages/man5/passwd.5.html (man 5 passwd)
^ shadow-utils is expecting 7 fields.
We're making assumptions about these fields later on, I think it'd be safer to loudly fail if the file we're modifying is not in the format we're expecting rather than silentlly ignoring the line.
| } | ||
| base | ||
| } | ||
| _ => "/bin/sh", |
There was a problem hiding this comment.
Technically, we can't necessarily assume /bin/sh exists from POSIX:
Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_16
I looked at it, there's sadly no function able to resolve absolute paths from $PATH in the rust standard library. We'd have to parse the PATH and have a look in each directory manually. Or use the which crate. Or shell out to which.
Sounds like a lot of efforts for a nit. Let's ignore this for now.
If we were up to go that route, we could be a bit more fancy and try to find the shell set in the system-manager config on the host system.
I'd assume people using fish or zsh on system-manager are likely to have it installed on their host system as well.
That being said, we need to manually look in PATH to find the appropriate path for these shells.
2 participants
During deactivation, scan /etc/passwd for shells under /run/system-manager/sw/ and restore them to FHS paths.
Shell restoration is best-effort: errors are logged but do not prevent deactivation from completing.
This fixes #371