Bug 1277700 - logins are slow when system swamped[workaround]
logins are slow when system swamped[workaround]
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Václav Pavlín
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-03 16:01 EST by Richard Jasmin
Modified: 2015-11-03 16:48 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-03 16:48:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Jasmin 2015-11-03 16:01:58 EST
Description of problem:
Logins are slow during high disk usage activity or high system load.I have a workaround for this, but it may take a little more effort than just this due to security concerns.

Alright.
The idea is such that we cache all critical files in RAM(isnt this done anyways? ), including the shadow passwords for the system so that logins are moments.RAM is WAAAAAY faster than storage media, and proper caching of files such as these results in an unbreakable and uninterrupt-able system that is always available. THIS SHOULD BE THE NORM FOR ALL LINUX.

However, as password files can now be yanked from RAM, especially if always stored at a central address some method must be used to secure them that the end user needs not be aware of. XTEA comes to mind. Its light and the CPU can even use it to decode instructions destined to it on the fly.Ive seen the code for some sample dev OS (anonymous??) in C, so I know this is possible to do.


This prevents password snooping of said data.The password section of RAM could be XTEA, or at least the password file location, to prevent people from scraping passwords from RAM. Cracking seems a moot point but would be possible if this data is not scrambled in some way.
Aparently some Debian folk think Im spreading FUD about SHA1 being quasi-cracked and collided.Would you chance it? Im not.

Version-Release number of selected component (if applicable):
21+

How reproducible:
every login, given said circumstance

Steps to Reproduce:
1.load the system. (spin something, etc. etc.)
2.login


Actual results:
DELAY ......

Expected results:
SNAPPY system
Comment 1 Kevin Fenzi 2015-11-03 16:48:50 EST
The linux kernel already caches as much information as its able to in ram. 

If you have some idea for how it could handle things better, please talk to the linux-kernel mailing list.

Note You need to log in before you can comment on or make changes to this bug.