[JIRA] [matrix-auth-plugin] (JENKINS-26824) Easy to accidentally modify wrong user using many plugins and many users
Thomas Herrlin
updated JENKINS-26824
Easy to accidentally modify wrong user using many plugins and many users
Clarification: Too easy to make mistakes relative to the potential consequences.
Change By:
Thomas Herrlin
(06/Feb/15 9:29 AM)
Description:
Rootproblem:Globalpermissionmatrixtoowidetoshowleftmostusernamewhenusingrightmosttogglepermissionsordeleteuserbuttons.Thisappliesforalargenumberofusernamesandpluginsthatrequirepermissions.Exampleusecases:*Itistooeasy
(relative
to
theconsequences)to
accidentallytoggleallpermissionsforAnonymouswhencreatinganewuser,asbotharenormallysortedlast.ThiswouldbereallybadforaninternetexposedJenkinsinstallation.*Itistooeasytoaccidentallydeletethewronguser(redXrightmost).Suggestedimprovements:*tr.permission-row:hover{background:#99;}*Somesortofunobtrusivepopupdisplayofusernameandpermissionnameaffectedwhenhoveringovercheckbox,deleteortogglepermissionsinmatrix.*Namecolumnduplicatedtotheright.*RemovetogglepermissionsfortheAnonymoususer.OratleastpopupaconfirmationboxjustforAnonymous.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [matrix-auth-plugin] (JENKINS-26824) Easy to accidentally modify wrong user using many plugins and many users
Thomas Herrlin
created JENKINS-26824
Easy to accidentally modify wrong user using many plugins and many users
Issue Type:
Improvement
Assignee:
Jesse Glick
Components:
matrix-auth-plugin
Created:
06/Feb/15 9:15 AM
Description:
Root problem:
Global permission matrix too wide to show leftmost username when using right most toggle permissions or delete user buttons.
This applies for a large number of usernames and plugins that require permissions.
Example usecases:
It is too easy to accidentally toggle all permissions for "Anonymous" when creating a new user, as both are normally sorted last. This would be really bad for an internet exposed Jenkins installation.
It is too easy to accidentally delete the wrong user (red X rightmost).
Suggested improvements:
tr.permission-row:hover { background: #99; }
Some sort of unobtrusive popup display of username and permission name affected when hovering over checkbox, delete or "toggle permissions" in matrix.
Name column duplicated to the right.
Remove toggle permissions for the "Anonymous" user. Or at least popup a confirmation box just for "Anonymous".
Environment:
Jenkins 1.580.3. Matrix auth 1.2. LDAP auth. Lots of plugins and users.
Project:
Jenkins
Labels:
plugin
security
user-experience
configuration
Priority:
Minor
Reporter:
Thomas Herrlin
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-22993) Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag.
Thomas Herrlin edited a comment on JENKINS-22993 Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag. Probably related to https://issues.jenkins-ci.org/browse/JENKINS-23098 Preliminary tests in lab environment indicate that it has been fixed with maven plugin 2.5. Tested on Jenkins 1.554.3 with my attached simple maven project. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-22993) Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag.
Thomas Herrlin commented on JENKINS-22993 Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag. Probably related to https://issues.jenkins-ci.org/browse/JENKINS-23098 Preliminary tests in lab environment indicate that it has been fixed with maven plugin 2.5 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin commented on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace I have confirmed integration of fix between 0.20 and 0.21 with a simple testcase: Execute shell: mkdir -p a touch a/a.file ln -s a b Delete workspace when build is done: Apply pattern also on directories: False Exclude: a/a.file Version 0.20: a and b are preserved. a/a.file deleted (via symlink b). Version 0.21: a and a/a.file are preserved. b deleted (b treated as a file). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin commented on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace Replicated problem with workspace cleanup 0.20, Jenkins 1.554.1-LTS and SSH slaves 1.6. In the default mode without any include/exclude ant patterns the symlinks are NOT followed. Using the "advanced" include/exclude ant patterns causes the plugin to follow symlinks outside of the workspace and can potentially delete a lot of data. Also if only adding a single exclude "foobar" rule, the default non specified include will follow symlinks. All the tools and libraries I have used so far for deleting entire directory structures (python shutil.rmtree, rm -r, etc...) are not following symlinks per default. Thankfully we had recent automatic snapshot backups of the non workspace data. An accidental symlink to the "/" directory is significant for installations with large NFS mounts. Even with backups or snapshots, it causes downtime for restoration. I would call this dangerous behavior and not just weird behavior. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin commented on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace Untested proposal: hudson.plugins.ws_cleanup.Cleanup: DirectoryScanner ds = new DirectoryScanner(); + ds.setFollowSymlinks(false); // Or make it a GUI option (default false). I have no experience with Jenkins GUI development. In org.apache.tools.ant.DirectoryScanner the default seems to be set to true: /** Whether or not symbolic links should be followed. * @since Ant 1.5 */ private boolean followSymlinks = true; This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin edited a comment on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace Untested proposal: hudson.plugins.ws_cleanup.Cleanup: Cleanup.java DirectoryScanner ds = new DirectoryScanner(); + ds.setFollowSymlinks(false); // Or make it a GUI option (default false). I have no experience with Jenkins GUI development. In org.apache.tools.ant.DirectoryScanner the default seems to be set to true: DirectoryScanner.java /** * Whether or not symbolic links should be followed. * * @since Ant 1.5 */ private boolean followSymlinks = true; This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin commented on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace hudson.Util.deleteRecursive() that is used by Cleanup.java does not seem to follow symlinks itself. Best guess it that default behavior is calling deleteRecursive on the top directory first and deletes the symlink before it can be traversed, and the advanced is causing a depth first recursion to occur. But this is just a hypothesis. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin
commented on JENKINS-13444
Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Did some testing and my patch works with the exception that symlinks are no longer deleted themselves.
Probably need to process ds.getNotFollowedSymlinks() as well.
Also checked that not using ant patterns changes the behavior to only use workspace.deleteRecursive() that is symlink safe (it calls Util.deleteRecursive):
WsCleanup.java
if ((patterns == null || patterns.isEmpty()) (externalDelete == null || externalDelete.isEmpty())) {
workspace.deleteRecursive();
} else {
workspace.act(new Cleanup(...));
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [ws-cleanup] (JENKINS-13444) Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace
Thomas Herrlin commented on JENKINS-13444 Workspace Cleanup plugin seems to be following symlinks and deleting files outside its workspace Created a pull request with my purposed fix: https://github.com/jenkinsci/ws-cleanup-plugin/pull/15 I have only done basic testing and my gut feeling is that it may need more testing. I may look into writing unittests for this plugin if the jenkins/maven framework for that is not too complicated. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-slaves] (JENKINS-22320) High CPU consumption because of SSH communication
Thomas Herrlin
commented on JENKINS-22320
High CPU consumption because of SSH communication
Preliminary tests where actually not so good. Forgot to remove the java exclusions when using the jvisualvm CPU sampler. Majority of CPU time still within socketRead0native even after my buffer hack.
Also tried forcing setTcpNoDelay(false) as src/main/java/hudson/plugins/sshslaves/SSHLauncher.java sets connection.setTCPNoDelay(true).
Setting to false should reduce the number of packets and thus the amount of interrupts.
TCPNoDelay should mostly be used for interactive connections to get fast non piggybacked ACKs and not so good for bulk transfers as far as I understand. I find commit c2fcc257 in sshslaves to be contradictory to my understanding on how the TCP protocol works, but perhaps there are some cases in the real world where ACK piggybacking causes problems.
Did a simple "ifconfig ; sleep 3 ; ifconfig" while jenkins was transferring a big non-compressible mocked artifact, average RX packet size was about 1100 bytes.
SSH buffer size seems to be set to 4Mb in the sshslaves plugin:
src/main/java/hudson/plugins/sshslaves/SSHLauncher.java
private void expandChannelBufferSize(Session session, TaskListener listener) {
// see hudson.remoting.Channel.PIPE_WINDOW_SIZE for the discussion of why 1MB is in the right ball park
// but this particular session is where all the master/slave communication will happen, so
// it's worth using a bigger buffer to really better utilize bandwidth even when the latency is even larger
// (and since we are draining this pipe very rapidly, it's unlikely that we'll actually accumulate this much data)
int sz = 4;
m.invoke(session, sz*1024*1024);
I am using trilead-ssh2-build217-jenkins-3, sshslaves 1.6, Jenkins 1.554.1 with the bundled jetty container.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-slaves] (JENKINS-22320) High CPU consumption because of SSH communication
Thomas Herrlin commented on JENKINS-22320 High CPU consumption because of SSH communication Looks like I may be chasing a red herring The slowdowns I see may not actually be related to this ticket, even if I get high cpu usage in fill_buffer - socketRead0. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-slaves] (JENKINS-22320) High CPU consumption because of SSH communication
Thomas Herrlin commented on JENKINS-22320 High CPU consumption because of SSH communication I am currently experimenting with increasing the fill_buffer() buffer from 2Kb to 64Kb or even replacing it with BufferedReader. My first naive preliminary test looks good, but still too early to say for certain. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-slaves] (JENKINS-22320) High CPU consumption because of SSH communication
Thomas Herrlin edited a comment on JENKINS-22320 High CPU consumption because of SSH communication I am currently experimenting with increasing the fill_buffer() buffer from 2Kb to 64Kb or even replacing it with BufferedReader. My first naive preliminary test looks good, but still too early to say for certain. See trilead-ssh2-64K-buffer.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ssh-slaves] (JENKINS-22320) High CPU consumption because of SSH communication
Thomas Herrlin updated JENKINS-22320 High CPU consumption because of SSH communication Change By: Thomas Herrlin (19/May/14 12:37 PM) Attachment: trilead-ssh2-64K-buffer.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-22993) Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag.
Thomas Herrlin created JENKINS-22993 Maven plugin version 2.3 freezes the ssh node if it runs with the mvn -T flag. Issue Type: Bug Assignee: Unassigned Attachments: jenkins.jstack.xz, simpleproject.tar.xz, slave.jstack.xz Components: maven Created: 13/May/14 8:50 AM Description: The problem started occurring after upgrading from maven plugin 2.1. The node becomes entirely unresponsive and any other builds or scm pollings also freeze on that node. The jenkins node need to be manually reconnected to clear the fault. If a git SCM poll was active on the node then the jenkins master must be restarted for the polling status page to clear. The problem does not seem to be intermittent and is easy to reproduce for us. Attaching jstacks and a mocked multimodule job that replicates the problem. Using SSH slaves plugin 1.6 and Jenkins LTS 1.554.1. Java 7u51 x86-64. Running on the master node without ssh slave plugin does not cause a freeze. Running without the -T flag does not cause a freeze. Running with maven-plugin 2.1 does not cause a freeze. Have not tested with maven plugin version 2.2. Tested with maven 3.1.1. Maven 3.2.1 with -T flag does not seem supported by the plugin at all. Goals: compile -T 4 MAVEN_OPTS=-Xms128M -Xmx1G -verbose:gc Jenkins is started via ubuntu upstart with the "java -jar jenkins.war" method. It is however manually installed. Jenkins JVM options: -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/tmp/jenkins-test/loggc.txt -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -Xmx1024m -Xms1024m -XX:SoftRefLRUPolicyMSPerMB=2000 -XX:MaxPermSize=192m -server -Djava.awt.headless=true -Dhudson.master.headless=true -Dhudson.webstart.headless=true -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true -DJENKINS_HOME=/local/jenkins-test -jar /local/jenkins-test/jenkins.war --javaHome=/opt/local/dev_tools/java/x64/jdk1.7.0_51/jre --prefix=/jenkins --logfile=/local/jenkins-test/jenkins.log --httpListenAddress=127.0.0.1 --httpPort=18080 --httpsListenAddress=127.0.0.1 --httpsPort=-1 --ajp13ListenAddress=127.0.0.1 --ajp13Port=-1 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20 Node JVM options: -Xms8m -Xmx128m -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/local/jenkins-test-agents/jenkinsadm/loggc.txt -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 No out of memory problem indications in -Xloggc or -verbose:gc. I have tried with and without these, no effect: Use private Maven repository: Local to workspace Run headless Disable triggering of downstream projects Disable automatic site documentation artifact archiving Disable automatic artifact archiving The "Build modules in parallel" functionality is not a viable option for us, we require that the build be done within the same job. Tried both with and without the "chrt -b 0" batch scheduler. Normally we start the nodes with the batch scheduler as a prefix. Tried to run nodes both on RHEL 6.2 over lan and Ubuntu 14.04 on localhost. Both are multicore machines. I have renamed some server and usernames for security reasons. Hanging job name: ThomasHerrlin_ticket_3348 Hanging slave node: server030 Jenkins console output: ... Executing Maven: -B -f /ssd/jenkins-test-agents/jenkinsadm/workspace/ThomasHerrlin_ticket_3348/pom.xml -T4 compile GC 33024K-4405K(125952K), 0.0085580 secs GC 37429K-6340K(125952K), 0.0109360 secs INFO Scanning for projects... INFO INFO Reactor Build Order: INFO INFO my-app1 INFO my-app2 INFO my-app3 INFO my-app4 INFO buildall_test HUDSON Collecting dependencies info HUDSON Collecting dependencies infoINFO Building with 4 threads HUDSON Collecting dependencies info HUDSON Collecting dependencies info At this point it freezes. Environment: Linux RHEL 6.2 and Ubuntu 14.04. x86-64.
