Created attachment 58339 [details] [review]
Add spawn_with_uid() helper function

Similar to spawn_with_login_uid() function.

Created attachment 58340 [details] [review]
Fix disabling passwords

passwd requires root when "-d" is passed.

I don't think is right.

a loginuid is different than a uid.  it's a number that starts at 0 and increments any time a user logs in to the system.

In this way you can trace a process back to the session it started from.

If things are failing now it's probably because the loginuid can't be set anymore, it's now an immutable object for the kernel, I believe.

comment 3 is incorrect. i was confusing loginuid and sessionid (the latter gets incremented when the former gets set)

Looks like we need this for the chage call too.

So my question is, why did it work before?

okay, so let's back up. 

1) spawn_with_login_uid doesn't change the uid of the process.  It only spoofs the loginuid of the process, which is the uid that the user who started the process supposedly logged in with.

2) accountsservice runs as root, regardless

3) All of these commands should work irregardless of what the loginuid is, since e.g. sudo passwd -d whould work and sudo isn't going to change the loginuid.

Are you sure this is broken for you?

(In reply to comment #6)
> okay, so let's back up. 
> 
> 1) spawn_with_login_uid doesn't change the uid of the process.  It only spoofs
> the loginuid of the process, which is the uid that the user who started the
> process supposedly logged in with.
> 
> 2) accountsservice runs as root, regardless
> 
> 3) All of these commands should work irregardless of what the loginuid is,
> since e.g. sudo passwd -d whould work and sudo isn't going to change the
> loginuid.
> 
> Are you sure this is broken for you?

It certainly was broken, though I'm not certain how passwd or chage actually do their work (so which checks they make). In my tests, passwd only worked when launched with a terminal. I'm not sure it's the fix, but it doesn't hurt.

passwd only worked when accountsservice was launched from a terminal? when control-center was launched from a terminal?

(In reply to comment #8)
> passwd only worked when accountsservice was launched from a terminal? when
> control-center was launched from a terminal?

When accountsservice was launched from a terminal. It didn't seem to work when autostarted.

so if accountsservice is autostarted you'd expect it's loginuid to be -1. Your patch makes us not set the loginuid at all. 

I wonder if selinux and/or the kernel now blocks setting the loginuid and is killing our program for even trying?

(In reply to comment #10)
> so if accountsservice is autostarted you'd expect it's loginuid to be -1. Your
> patch makes us not set the loginuid at all. 
> 
> I wonder if selinux and/or the kernel now blocks setting the loginuid and is
> killing our program for even trying?

I run SELinux in permissive mode, but it could still be causing problems:
* Fri Jan 27 2012 Tomas Mraz <tmraz@redhat.com> 0.78.99-1
- use better (auditable) libselinux calls for checking
  the access to passwd (#518268)

Can this bug be closed? I assume it was just some transient rawhide problem that went away?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/5.