So, I haven't changed anything significant in how the F20 cloud images are generated from how the F19 ones were. But now, when I try to log into one after booting, cloud-init runs and appears to configure everything, but sshing in gives
/bin/bash: Permission denied
In the logs:
Jul 19 14:56:50 localhost sshd[621]: ssh_selinux_change_context: setcon system_u:system_r:sshd_net_t:s0 from system_u:system_r:kernel_t:s0 failed with Permission denied [preauth] Jul 19 14:56:51 localhost sshd[621]: Accepted publickey for fedora from 192.168.77.1 port 40992 ssh2 Jul 19 14:56:51 localhost systemd: Starting user-1000.slice. Jul 19 14:56:51 localhost systemd: Created slice user-1000.slice. Jul 19 14:56:51 localhost systemd: Starting User Manager for 1000... Jul 19 14:56:51 localhost systemd: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Jul 19 14:56:51 localhost systemd: Starting Session 1 of user fedora. Jul 19 14:56:51 localhost systemd-logind: New session 1 of user fedora. Jul 19 14:56:51 localhost systemd: Started Session 1 of user fedora. Jul 19 14:56:51 localhost systemd: Started User Manager for 1000. Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session opened for user fedora by (uid=0) Jul 19 14:56:51 localhost sshd[627]: ssh_selinux_copy_context: setcon failed with Permission denied Jul 19 14:56:51 localhost sshd[627]: Received disconnect from 192.168.77.1: 11: disconnected by user Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session closed for user fedora Jul 19 14:56:51 localhost systemd-logind: Removed session 1. Jul 19 14:56:51 localhost systemd: Stopping user-1000.slice. Jul 19 14:56:51 localhost systemd: Removed slice user-1000.slice
Is this a policy bug? Something new which is failing on image build? Something else?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/19/2013 11:10 AM, Matthew Miller wrote:
So, I haven't changed anything significant in how the F20 cloud images are generated from how the F19 ones were. But now, when I try to log into one after booting, cloud-init runs and appears to configure everything, but sshing in gives
/bin/bash: Permission denied
Usually means your system is mislabeled. I would bet that sshd is not running as sshd_t. Something went wrong when you built the image.
In the logs:
Jul 19 14:56:50 localhost sshd[621]: ssh_selinux_change_context: setcon system_u:system_r:sshd_net_t:s0 from system_u:system_r:kernel_t:s0 failed with Permission denied [preauth] Jul 19 14:56:51 localhost sshd[621]: Accepted publickey for fedora from 192.168.77.1 port 40992 ssh2 Jul 19 14:56:51 localhost systemd: Starting user-1000.slice. Jul 19 14:56:51 localhost systemd: Created slice user-1000.slice. Jul 19 14:56:51 localhost systemd: Starting User Manager for 1000... Jul 19 14:56:51 localhost systemd: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Jul 19 14:56:51 localhost systemd: Starting Session 1 of user fedora. Jul 19 14:56:51 localhost systemd-logind: New session 1 of user fedora. Jul 19 14:56:51 localhost systemd: Started Session 1 of user fedora. Jul 19 14:56:51 localhost systemd: Started User Manager for 1000. Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session opened for user fedora by (uid=0) Jul 19 14:56:51 localhost sshd[627]: ssh_selinux_copy_context: setcon failed with Permission denied Jul 19 14:56:51 localhost sshd[627]: Received disconnect from 192.168.77.1: 11: disconnected by user Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session closed for user fedora Jul 19 14:56:51 localhost systemd-logind: Removed session 1. Jul 19 14:56:51 localhost systemd: Stopping user-1000.slice. Jul 19 14:56:51 localhost systemd: Removed slice user-1000.slice
Is this a policy bug? Something new which is failing on image build? Something else?
On Fri, Jul 19, 2013 at 05:54:38PM -0400, Daniel J Walsh wrote:
Usually means your system is mislabeled. I would bet that sshd is not running as sshd_t. Something went wrong when you built the image.
Hmmmm. It _is_ doing this. I think that's new. :)
Installing: policycoreutils ##################### [156/232] Installing: selinux-policy ##################### [157/232] semodule: SELinux policy is not managed or store cannot be accessed.
Any idea what that's all about?
(This is with appliance-creator -- we haven't yet switched to oz.)
On Fri, Jul 19, 2013 at 08:42:05PM -0400, Matthew Miller wrote:
Hmmmm. It _is_ doing this. I think that's new. :) Installing: policycoreutils ##################### [156/232] Installing: selinux-policy ##################### [157/232] semodule: SELinux policy is not managed or store cannot be accessed. Any idea what that's all about? (This is with appliance-creator -- we haven't yet switched to oz.)
I put
/usr/sbin/fixfiles -R -a restore
at the end of my kickstart %post. That ain't staying, but it did fix the problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/19/2013 09:19 PM, Matthew Miller wrote:
On Fri, Jul 19, 2013 at 08:42:05PM -0400, Matthew Miller wrote:
Hmmmm. It _is_ doing this. I think that's new. :) Installing: policycoreutils ##################### [156/232] Installing: selinux-policy ##################### [157/232] semodule: SELinux policy is not managed or store cannot be accessed. Any idea what that's all about? (This is with appliance-creator -- we haven't yet switched to oz.)
I put
/usr/sbin/fixfiles -R -a restore
at the end of my kickstart %post. That ain't staying, but it did fix the problem.
That is actually supposed to be done in the post at least in livecd-creator.
On Sun, Jul 21, 2013 at 06:43:02AM -0400, Daniel J Walsh wrote:
at the end of my kickstart %post. That ain't staying, but it did fix the problem.
That is actually supposed to be done in the post at least in livecd-creator.
Huh. Well, we sure weren't with the cloud images using appliance-creator. If we use an anaconda-in-a-vm type of image creation, this wouldn't be necessary, right?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2013 04:37 PM, Matthew Miller wrote:
On Sun, Jul 21, 2013 at 06:43:02AM -0400, Daniel J Walsh wrote:
at the end of my kickstart %post. That ain't staying, but it did fix the problem.
That is actually supposed to be done in the post at least in livecd-creator.
Huh. Well, we sure weren't with the cloud images using appliance-creator. If we use an anaconda-in-a-vm type of image creation, this wouldn't be necessary, right?
I would figure not if anaconda is doing the work. If you do the equivalent of setup followed by yum install into a chroot, then you probably need to relabel the content that was created in the setup phase.
Also if you do not use a separate kernel during your install then SELinux should probably be "disabled" from the chroot point of view, so no apps attempt to "load_policy". Since we would not policy loaded from a chrooted build on say F20 happening on a F18 build system.
On Mon, Jul 22, 2013 at 09:41:04AM -0400, Daniel J Walsh wrote:
Also if you do not use a separate kernel during your install then SELinux should probably be "disabled" from the chroot point of view, so no apps attempt to "load_policy". Since we would not policy loaded from a chrooted build on say F20 happening on a F18 build system.
Or, say, F20 on RHEL6, which is the koji builder environment.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/22/2013 09:44 AM, Matthew Miller wrote:
On Mon, Jul 22, 2013 at 09:41:04AM -0400, Daniel J Walsh wrote:
Also if you do not use a separate kernel during your install then SELinux should probably be "disabled" from the chroot point of view, so no apps attempt to "load_policy". Since we would not policy loaded from a chrooted build on say F20 happening on a F18 build system.
Or, say, F20 on RHEL6, which is the koji builder environment.
Yes we need to make sure F20 policy never loads on an RHEL6 machine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/19/2013 08:42 PM, Matthew Miller wrote:
On Fri, Jul 19, 2013 at 05:54:38PM -0400, Daniel J Walsh wrote:
Usually means your system is mislabeled. I would bet that sshd is not running as sshd_t. Something went wrong when you built the image.
Hmmmm. It _is_ doing this. I think that's new. :)
Installing: policycoreutils ##################### [156/232] Installing: selinux-policy ##################### [157/232] semodule: SELinux policy is not managed or store cannot be accessed.
Any idea what that's all about?
(This is with appliance-creator -- we haven't yet switched to oz.)
Usually this means that the semanage commands are not running with privs, IE can't write to /etc/selinux/targeted directories.
selinux@lists.fedoraproject.org