'sudo xl console', login asks for password for user 'user'

[adrelanos]

Works passwordless for user 'root' but not for user 'user. Both, Fedora and Debian templates are affected.

[unman]

@adrelanos
I think this is expected behaviour. You could delete password for user, but wouldn't that break the passwordless su? It could be done through pam I guess.
In what use case would you want console access where you didnt want to open a term? The only times I've used xl console is where there's some boot/X issue and then root is what I want.

[unman]

@adrelanos
I think this is expected behaviour. You could delete password for user, but wouldn't that break the passwordless su? It could be done through pam I guess.
In what use case would you want console access where you didnt want to open a term? The only times I've used xl console is where there's some boot/X issue and then root is what I want.

[adrelanos]

You could delete password for user, but wouldn't that break the passwordless su?

Just now tested sudo passwd user -d. Now passwordless login as both, user or root, functional. Also sudo is still functional.

In what use case would you want console access where you didnt want to open a term? The only times I've used xl console is where there's some boot/X issue and then root is what I want.

Exactly in that use case. But also in exactly these problematic cases it's very good to avoid further confusion and not to add more hurdles [or riddles] for the one trying to provide debug information.

Can someone advice please, where the code is that allows passwordless login for the root user?

[adrelanos]

You could delete password for user, but wouldn't that break the passwordless su?

Just now tested sudo passwd user -d. Now passwordless login as both, user or root, functional. Also sudo is still functional.

In what use case would you want console access where you didnt want to open a term? The only times I've used xl console is where there's some boot/X issue and then root is what I want.

Exactly in that use case. But also in exactly these problematic cases it's very good to avoid further confusion and not to add more hurdles [or riddles] for the one trying to provide debug information.

Can someone advice please, where the code is that allows passwordless login for the root user?

[unman]

If you look in /etc/shadow you'll see root has no password set.
Then in /etc/pam/d.common--auth pam_unix.so is set nullok_secure:
this allows access with a blank password to a tty in /etc/securetty.
Finally console will appear in /etc/securetty

[unman]

If you look in /etc/shadow you'll see root has no password set.
Then in /etc/pam/d.common--auth pam_unix.so is set nullok_secure:
this allows access with a blank password to a tty in /etc/securetty.
Finally console will appear in /etc/securetty

[adrelanos]

We could get away with this by modifying https://github.com/marmarek/qubes-core-agent-linux/blob/master/debian/qubes-core-agent.preinst.

useradd --user-group --create-home --shell /bin/bash user
->
useradd --password "" --user-group --create-home --shell /bin/bash user

[adrelanos]

We could get away with this by modifying https://github.com/marmarek/qubes-core-agent-linux/blob/master/debian/qubes-core-agent.preinst.

useradd --user-group --create-home --shell /bin/bash user
->
useradd --password "" --user-group --create-home --shell /bin/bash user

[marmarek]

I'm ok with this change. Are you going to commit this?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

I'm ok with this change. Are you going to commit this?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Yes, pull request attached above.

I was wondering if this should be fixed in existing images during upgrade as well by running sudo passwd user -d. Do we care about this? But I am not sure I am getting lost in complexity here. The command would have to be protected by a run-only-once status file mechanism, so users who decided to use protections by user passwords / sudo would not always end up having their user password deleted - do we care about those? And if one wanted to go crazy about this, a protected file mechanism to opt-out beforehand would be required.

[adrelanos]

Yes, pull request attached above.

I was wondering if this should be fixed in existing images during upgrade as well by running sudo passwd user -d. Do we care about this? But I am not sure I am getting lost in complexity here. The command would have to be protected by a run-only-once status file mechanism, so users who decided to use protections by user passwords / sudo would not always end up having their user password deleted - do we care about those? And if one wanted to go crazy about this, a protected file mechanism to opt-out beforehand would be required.

[marmarek]

Theoretically we could check for:

1. The current value ("!")
2. Previous package version (so it gets run only on upgrade from before
   3.0.15).

But I think we could also simply ignore this.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Theoretically we could check for:

1. The current value ("!")
2. Previous package version (so it gets run only on upgrade from before
   3.0.15).

But I think we could also simply ignore this.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Theoretically we could check for:

1. The current value ("!")

Done in above pull request.

[adrelanos]

Theoretically we could check for:

1. The current value ("!")

Done in above pull request.

[adrelanos]

Please reopen.

Can someone confirm, that newly created Debian templates that never upgraded qubes-core-agent before, can login sudo xl console vm-name with user user?

Looking at qubes-core-agent-linux preinst it creates user user without password only if that user does not yet exist.

But qubes-builder-debian prepare-chroot-debian uses useradd -g user $USER_OPTS -m user so the user will already be existing, if I am not mistaken.

Below.

usermod -p '' root

We should add.

usermod -p '' user

[adrelanos]

Please reopen.

Can someone confirm, that newly created Debian templates that never upgraded qubes-core-agent before, can login sudo xl console vm-name with user user?

Looking at qubes-core-agent-linux preinst it creates user user without password only if that user does not yet exist.

But qubes-builder-debian prepare-chroot-debian uses useradd -g user $USER_OPTS -m user so the user will already be existing, if I am not mistaken.

Below.

usermod -p '' root

We should add.

usermod -p '' user

[unman]

@andrewdavidwong Confirmed this issue still arises in 3.2 milestone for Fedora template

[unman]

@andrewdavidwong Confirmed this issue still arises in 3.2 milestone for Fedora template

[schnurentwickler]

In current release (Qubes 4.0) the usage of sudo xl console -t pv VMname in dom0 does give me access to console in standard fedora-26, but only passwordless into root. The account user wants a password I do not know or have set / deleted.
In fedora-28-minimal without the packages qubes-core-agent-passwordless-root and polkit, both root and user account are not able to login via sudo xl console.
Root access via xl console should not depend on passwordless-root and polkit, should it?
I thought the passwordless-root package only set up sudo usage for an user shell.

But to get control qvm-run -u root fedora-28 xterm does give me a root shell.

[schnurentwickler]

In current release (Qubes 4.0) the usage of sudo xl console -t pv VMname in dom0 does give me access to console in standard fedora-26, but only passwordless into root. The account user wants a password I do not know or have set / deleted.
In fedora-28-minimal without the packages qubes-core-agent-passwordless-root and polkit, both root and user account are not able to login via sudo xl console.
Root access via xl console should not depend on passwordless-root and polkit, should it?
I thought the passwordless-root package only set up sudo usage for an user shell.

But to get control qvm-run -u root fedora-28 xterm does give me a root shell.