Bug 336204

Summary: Yast2 is broken
Product: [openSUSE] openSUSE 10.3 Reporter: Maximilian Bianco <maximilian_bianco>
Component: YaST2Assignee: E-mail List <bnc-team-screening>
Status: RESOLVED DUPLICATE QA Contact: Jiri Srain <jsrain>
Severity: Critical    
Priority: P5 - None    
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 10.3   
Whiteboard:
Found By: Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Maximilian Bianco 2007-10-24 02:10:39 UTC
I have done this on two machines so far.....go into administrator settings and get prompted for a password....enter whatever i want and bam i'm in. I first noticed it at work today. I mess around with alot of hardware and i have been installing different distros on some old and not so old boxes. Anyway i usually use one or two variations on one or two passwords for these machines since it's largely for testing purposes. Today i was playing with samba configuration and went into system administration applet and couldn't quite remember which password i had used but i got lucky on the first try or so i thought... a little while later i fired up a superuser terminal and the password i had used earlier was rejected...thought i had mistyped and tried again 3 or 4 times just to be sure and rejected! I went back to yast and got right in...so then i tried some gibberish and presto i was into yast. I couldn't believe it. I tried to submit a bug report but something went awry and i could not. In any case i went home and tried this here on a totally different machine with a different setup and what do you know ....gibberish lets me log in to yast.....not into the terminal....this is seriously f**ked up!! what's even stranger after a while it goes back to working the way it should.....both times i noticed this phenomena was right after updates.
Comment 1 Stephan Binner 2007-10-24 07:05:52 UTC
The password is only not required for 5 minutes unless overridden otherwise in
/etc/sudoers with "timestamp_timeout = 0".

*** This bug has been marked as a duplicate of bug 216796 ***