[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Do not plan to support /usr/lib/pam.d for Debian pam

On Sep 15, Sam Hartman <hartmans@debian.org> wrote:

> But for the most part PAM appears to just override on a file-by-file
> basis.
Just like udev, kmod, dbus, etc...
PAM is not different.

> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the week.
> What I heard is that there was no project consensus to do this, and that
> people were running experiments to see what is possible.
Indeed. I did the experiments and they where unexpectedly positive:
pam is the only blocker for booting _the base system_.
I never expected that everything would immediately work just fine with 
an empty /etc: my goal is to have support for this in the base system 
and selected packages.

See for yourself:

mkdir /var/lib/machines/empty/
ln -s usr/bin usr/sbin usr/lib usr/lib64 /var/lib/machines/empty/
# this is a workaround for PAM
mkdir /var/lib/machines/empty/etc/
cp -a /etc/pam.d /etc/security /var/lib/machines/empty/etc/
# this is a workaround for https://github.com/systemd/systemd/issues/29185
echo ID=unknown > /var/lib/machines/empty/etc/os-release

systemd-nspawn --private-network --network-veth -b \
  --bind-ro=/usr --tmpfs=/var/ --tmpfs=/tmp/ \
  -D /var/lib/machines/empty/

You could add --tmpfs=/etc/ too, but then logins would fail.


Attachment: signature.asc
Description: PGP signature

Reply to: