Hide Forgot
== Comment: #0 - Shubham Goyal <shubgoya.com> - 2013-11-05 03:40:18 == Description of problem: It seems that strict password checking is not working while authenticating for vnc password after starting vnc server. I gave '123456789' as vnc password but could connect to vnc server using below passwords as well: '12345678' '1234567890' '12345678901234' I believe that a user should be able to connect to vnc server only if he provides a exact valid password which was provided earlier before starting vnc server. How reproducible: Always Version-Release number of selected component (if applicable): 3.11.0-300.fc20.ppc64p7 : junoiocplus2-lp4 Steps to Reproduce: 1) Trigger a new vnc installation & provide a password to authenticate connection to vnc server. 2) Try passwords (like mentioned above) which are deviating from original password. 3) You will be able to connect to vnc server. Actual results: Able to connect to vnc server even with wrong passwords Expected results: Installer should throw an error if user tries to connect with any password other than originally provided one. Additional info: Let me know if you need any.
I believe that the 8-character password is a limitation of the VNC protocol. Reassigning to tigervnc to confirm.
That's correct.
------- Comment From hamzy.com 2013-11-11 21:34 EDT------- Posted a potential patch to the ML: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-November/007114.html
This can (and should) be fixed in anaconda.
Posted another potential patch to the ML: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-November/007209.html
------- Comment From hannsj_uhl.com 2013-12-10 19:07 EDT------- *** Bug 100745 has been marked as a duplicate of this bug. ***
------- Comment From shubgoya.com 2013-12-19 11:03 EDT------- Am able to reproduce this bug in F20 PPC GA as well. Seems that the anaconda patch is not merged. Below is the ISO I used: http://ppc.koji.fedoraproject.org/stage/f20-20131215-GA-RC1.0/Fedora/ppc64/iso/ Thanks...
------- Comment From chavez.com 2014-01-22 22:17 EDT------- Hello Red Hat, Your bug states this is reportedly fixed in anaconda-19.31.42-1 which looks to be in snapshot 2. We received a similar report on s390x with snapshot 2 that states the following (below). Can you confirm the fix is there in snapshot 2 and whether the report from s390x testing is the same or a different problem please? We can mirror a new bug if you think it is a different problem. Thanks. =================================== The issue is observed while installing RHEL 7 snap2 on zvm Steps : 1. Start the installation 2. Provide all the parameters via parm file 3. Select vnc mode of installtaion 4 Provide the password as vnc12345 or abcd1234 5. Try connecting to vnc session with password as vnc12345 or abcd12345678 Actual - Able to login to the vnc session . The issue is not reproducible if the password length is less than 8 characters Anaconda do the substring match like if password is vnc12345 and user entered vnc123456 than we are able to login
(In reply to IBM Bug Proxy from comment #10) > ------- Comment From chavez.com 2014-01-22 22:17 EDT------- > Hello Red Hat, > > Your bug states this is reportedly fixed in anaconda-19.31.42-1 which looks > to be in snapshot 2. We received a similar report on s390x with snapshot 2 > that states the following (below). Can you confirm the fix is there in > snapshot 2 and whether the report from s390x testing is the same or a > different problem please? We can mirror a new bug if you think it is a > different problem. Thanks. > > =================================== > The issue is observed while installing RHEL 7 snap2 on zvm > > Steps : > 1. Start the installation > 2. Provide all the parameters via parm file I suppose 'parm file' means kickstart file, right? > 3. Select vnc mode of installtaion > 4 Provide the password as vnc12345 or abcd1234 > 5. Try connecting to vnc session with password as vnc12345 or abcd12345678 > > Actual - Able to login to the vnc session . The issue is not reproducible > if the password length is less than 8 characters > Anaconda do the substring match like if password is vnc12345 and user > entered vnc123456 than we are able to login It's not Anaconda who does the substring matching, it's VNC who generally uses only first 8 characters from the password. Anyway, this is a related but slightly different issue and it needs a patch in the pykickstart component, not the anaconda component. I'm gonna clone this bug and assign the cloned one to pykickstart.
This problem also occur on System z. It should be intrinsic, but just to be save: Please ensure that this fix and the fix for pykickstart component (RHBZ 1056939) get integrated for System z as well.
------- Comment From shubgoya.com 2014-02-13 09:42 EDT------- I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this issue is partially fixed. I gave '12345678' as vnc password. Below are the cases which I tried to connect via vnc server: '123456' - Not allowed to connect - This case is fixed '1234567890' - Still able to connect - Issue still persists So it seems that if the password tried (to connect vnc server) is a subset of the original password than proper checks are applied but if any additional characters are appended in the correct password than proper checking is not implemented. Ideally I should be able to connect only with the password I provided. Thanks...
(In reply to IBM Bug Proxy from comment #13) > ------- Comment From shubgoya.com 2014-02-13 09:42 EDT------- > I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this > issue is partially fixed. I gave '12345678' as vnc password. Below are the > cases which I tried to connect via vnc server: > > '123456' - Not allowed to connect - This case is fixed > > '1234567890' - Still able to connect - Issue still persists > > So it seems that if the password tried (to connect vnc server) is a subset > of the original password than proper checks are applied but if any > additional characters are appended in the correct password than proper > checking is not implemented. Ideally I should be able to connect only with > the password I provided. > > Thanks... The incorrect behaviour described above is a limitation of the VNC protocol itself and cannot be fixed in the Anaconda installer.
------- Comment From cdeadmin.com 2014-02-17 08:43 EDT-------
------- Comment From iranna.ankad.com 2014-02-24 13:36 EDT------- (In reply to comment #24) > (In reply to IBM Bug Proxy from comment #13) > > I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this > > issue is partially fixed. I gave '12345678' as vnc password. Below are the > > cases which I tried to connect via vnc server: > > > > '123456' - Not allowed to connect - This case is fixed > > > > '1234567890' - Still able to connect - Issue still persists > > > > So it seems that if the password tried (to connect vnc server) is a subset > > of the original password than proper checks are applied but if any > > additional characters are appended in the correct password than proper > > checking is not implemented. Ideally I should be able to connect only with > > the password I provided. > > > > Thanks... > The incorrect behaviour described above is a limitation of the VNC protocol > itself and cannot be fixed in the Anaconda installer. 1st case is important & good that it is fixed. I think 2nd case can be contained, its not of a concern. So..we are OK to close this bug. Thanks!
Verified according to comment 16.
*** Bug 1080641 has been marked as a duplicate of this bug. ***
Created attachment 878941 [details] anaconda.log SNAP10 default comment by bridge
Created attachment 878942 [details] anaconda.program.log SNAP10 default comment by bridge
Created attachment 878943 [details] anaconda.ifcfg.log SNAP10 default comment by bridge
Created attachment 878944 [details] anaconda.storage.log SNAP10 default comment by bridge
Created attachment 878945 [details] sosreport SNAP10 default comment by bridge
------- Comment From chavez.com 2014-05-06 13:38 EDT------- *** Bug 109963 has been marked as a duplicate of this bug. ***
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.