Bugzilla – Bug 923
argument list too long -- even with xargs
Last modified: 2020-06-02 19:44:14 MDT
It is necessary for sudo and xargs to coordinate in some fashion. Since I do not have this issue with other utilities, I'm guessing that sudo is the right utility to target. "xargs" is clearly able to fork and exec the "sudo" program, so it is unlikely that the limitation is an OS one. "sudo" should be able to fork and exec "chmod". $ xargs sudo chmod 666 <<<"$list" sudo: unable to execute /usr/bin/chmod: Argument list too long sudo: unable to execute /usr/bin/chmod: Argument list too long sudo: unable to execute /usr/bin/chmod: Argument list too long If there is a compelling reason for constraining the length of the argument list, then a method for determining the maximum should be provided so that xargs can be invoked with either the "-L" or "-n" option, limiting the number of arguments provided to "sudo". FYI: $ wc -l<<<"$list" 19686
That error comes from the kernel when sudo tried to execute the command. The problem is that the max size of the exec arguments (ARG_MAX) includes both the environment and the argument vector. The xargs utility assumes that the environment the command will be executed with is the same size as the current environment which is not necessarily the case with commands run via sudo which manipulates the environment. Specifically, it sets the SUDO_COMMAND environment variable to the command being executed. That effectively cuts in half the available space for arguments givenvery long command lines. This is fixed in https://www.sudo.ws/repos/sudo/rev/ff1fa8e3377f which truncates the command args at 4096 chars when formatting SUDO_COMMAND. That change will be part of sudo 1.9.0 when it is released next week.
That doesn't sound like it would actually work. Maybe I'm missing something. When "xargs" invokes "sudo", the arguments passed in are presumed to have been processed. If "sudo" then arbitrarily truncates its argument list, it will not have processed all the arguments it was given. If you are going to do something like this, minimally it is necessary to explain it in an *error* message (not warning because "sudo" isn't going to do what it was told to do). e.g. sudo error: only %u of %u arguments can be processed (list too long) Even then, since you are constraining the argument size to a number of characters instead of a number of arguments, it is going to be mind numbingly difficult to coordinate its use with xargs. If you feel compelled to use some arbitrary limit, please try to make the limitation be an argument count instead of a total-length-of-arguments count. With a little bit of trouble, you could count environment variables, subtract that from ARG_MAX and print an error message showing how many arguments could have been processed. Then, the limitation would not be arbitrary, but rather an OS limitations. Thank you!!
It is only the SUDO_COMMAND environment variable that is truncated, not the actual argument vector passed to execve(2).
Sorry. I misunderstood. Thank you!
Fixed in sudo 1.9.0.
Could you clarify why this change is safe / a good idea? Would it not be very confusing or potentially creating wrong behaviour if a program relies on SUDO_COMMAND, and sudo silently truncates it? The man page says `SUDO_COMMAND Set to the command run by sudo.`, it seems that should at least be updated to mention truncation?
This is what the manual page says in 1.9.0: SUDO_COMMAND Set to the command run by sudo, including command line arguments. The command line arguments are truncated at 4096 characters to prevent a potential execution error.