Ticket #1237 (closed bug: wontfix)

Opened 5 years ago

Last modified 5 years ago

Fedora people server should probably wait N days after forced password reset before moving ~ contents to fedora.bak

Reported by: rstrode Owned by: nobody
Priority: major Milestone:
Component: General Version:
Severity: Normal Keywords:
Cc: ajax@…, pertusus@… Blocked By:
Blocking: Sensitive:

Description

When the FAS password expires, people don't normally reset it right away, but instead reset it the next time they need to log in.

Unfortunately, it seems like right now all content on fedorapeople is moved to /home/fedora.bak when the reset happens, which breaks user web pages and links.

It would be better if there was a grace period before the user's content was moved, just to keep service reliable and to prevent the large number of users who don't reset in time from having to do extra work each password expiry period.

Change History

comment:1 Changed 5 years ago by mmcgrath

Just making a note on this, I can't imagine a scenario where this will be ok. When a user gets disabled or otherwise deactivated. Their stuff _must_ not be available anywhere public for both security reasons and legal reasons. So whatever solution we do come up with, it's got some pretty high requirements to be met.

We don't just do this stuff for fun or to piss people off, there's a reason for all of it.

I think the real solution here is to figure out how to better pick active users so they don't get disabled, or better figure out how to alert people prior to their password expiring.

comment:2 Changed 5 years ago by rstrode

I totally agree that a different mechanism for choosing inactive accounts would be a good solution to this problem. Maybe activity should key off of koji builds (or bugzilla?) in addition to the stuff that uses FAS passwords.

Another idea would be to make "auto-disabled" (paused?) accounts behave differently than explicitly deactivated accounts.

comment:3 Changed 5 years ago by toshio

I like the idea of using login to FAS-related services to determine activity. It one of the design considerations that went into FAS. This would include authenticated requests to elections, FAS, wiki, pkgdb, bodhi. (bodhi, elections, and wiki in particular seem like they'd provide a good deal of coverage).

koji does not auth against fas directly... however we do expire the certificates that koji uses for auth every six months. Getting a new cert requires logging into fas. There might also be a reasonably efficient way to query koji for builds and taking a set of names from that... but it sounds like a bit of coding which might not buy us much more than the cert-based timeout.

Bugzilla is going to be next to impossible to accurately and efficiently work with. If someone wants to contribute time to coding something that queries bugzilla monthly based on people who are coming close to an inactivity reset, that might be doable. I'm not inclined to want to code it myself, though.

cvs is ssh and cert based (cvs itself vs lookaside). We might be able to modify the scripts upload script and ssh authorized-keys, allowed to run what commands scripts to tell fas that there's been activity on the account. It will make those commands more complex, though. Not sure the benefit is worthwhile for the same reasons as koji.

comment:4 Changed 5 years ago by rstrode

Yea, querying

"Does the user have an invalid cert?"

would probably good enough for seeing if a packager is still active.

Between that and the wiki we've gotten the lion's share of contributors (I'm assuming QA and artists use the wiki). Triagers aren't getting accounted for though.

I guess we don't store bugzilla accounts in fas. Too bad we didn't have one shared sign on scheme (using just certs) then we could key off of "signed on".

comment:5 Changed 5 years ago by pertusus

  • Cc pertusus@… added

comment:6 Changed 5 years ago by mmcgrath

  • Status changed from new to closed
  • Resolution set to wontfix

Just cleaning up this older ticket.

1) Invalid users cannot have stuff published on Fedora people. 2) Users that go invalid and then back to valid, automatically have their dirs moved back. 3) We are reworking to verify when users are still active. One that is more transparent to the user.

Note: See TracTickets for help on using tickets.