On Fri, Dec 19, 2014 at 12:17 PM, R P Herrold <herrold@xxxxxxxxxxxx> wrote: > > Chris had contacted me off list yesterday, It was a gmail oops. > the OS/X method I am familiar entails booting from alternative > media (a different partition or from media on older hardware, > and one assumes from USB on newer, and essentially having a > guided loop mount to not just blank, but actually set a new > hard passwd in the credentials database). For 5 major releases (5 years), a 650MB Recovery HD volume is created at install time and boots into a minimal OS X: There's a Terminal program for doing password resets from, web browser, Disk Utility, and software restore. No password is needed for this environment. And single user mode boot is also possible without a password. > Windows is trickier as the credential 'lives' in a specific > hive segment in the registry (post Win 3.51 NT), and may > either be blanked, or have a hash of a credential stored on a > non-running client primary image, via a recovery instance > (sometimes secondary, sometimes media, etc) Looks like Windows has a really burdensome password reset. But startup repair doesn't require any authentication to get into, and this environment also includes access to a command line. So troubleshooting and fixing boot problems is still possible without a password. > > >> I'm not really grokking >> the point of systemd making single/emergency target locked down like >> this; physical access is assumed because in emergency mode there is no >> network. And physical access has always meant full access unless the >> volumes are encrypted. I'm a bit stumped how this is supposed to work >> without really esoteric knowledge. > > all great questions / observations, but the systemd folks are > not to be criticized. It gets tiresome I'm not aware that there's been a discussion. It's roughly the same time frame that anaconda lifted the set root password requirement, and systemd starting requiring one. So I just don't think the consequences of that combination was considered by anyone. I'll bring it up on desktop@. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
