Re: Integer Overflow in braces
Just FYI, if this were really a critical security issue, this is not how you should disclose it: https://www.reddit.com/r/netsec/comments/3h997d/bash_integer_overflow/ You have to first contact the maintainer in private, make sure the issue is acknowleged, fixed, and that the fix is available to most Bash users *before* disclosing anything. This just strikes me as a way to make yourself publicity. If you really want to help to fix Bash, instead of just complaining about some odd looking comments, provide patches... -- Eduardo Bustamante https://dualbus.me/
Re: remaking bash, trying static, glibc refuses static...?
On Wed, Aug 19, 2015 at 5:55 PM, Linda Walsh wrote: [cut a lot about dynamic linking and the linux kernel] > Even bash can load many of it's builtin's dynamically -- but if they > aren't there, it could use the same named-programs -- and I don't > think it "falls-over" and dies if it can't dynamically load a builtin -- > it just looks for the same name in the path. There are loadable builtins but I don't believe it is true that they can magically self-load as you describe. The closest this comes to the truth is that many builtins have corresponding programs in /bin, for the use of programs that don't have them builtin or for entities that might naïvely search the PATH looking for things which are legal to execute. (Some unices even include a /bin/cd for that reason, as pointless as that would otherwise be.) Did the rest of your message have anything to do with bash? You were trying to build a static version... you've been told how... was there more?
Re: -e does not take effects in subshell
Chet Ramey wrote: The earlier spec had -e only exit a script if a *simple* (external) command failed. It didn't include builtins nor functions. This is not; builtins and functions are simple commands. --- The builtins are _complex_ binary blobs that replace external commands. Functions are a collection of many commands. They are not a single, simple statement. I remember using their return value in some cases. With the change, I couldn't run a func and have it return the value in $? (1 byte, I know) -- but about 128x as flexible as "ok"/"die" (i.e. any non-zero value triggers the behavior now, but before, it didn't). My simplistic view was that -e was there to auto-exit if an external command failed because they are "out of your control". But if I write a function -- I design the behavior. Even if I designed in a bug -- it's still "my code" that has the problem not some -_e_xternal command cf. perl's option "autodie" -- you can say you want the "open builtin" to just die on errors, then for simple scripts you don't have to put extra code to handle each problem. I.e. -- it's not really something you want in production code, but I write far more throw away quick and dirty scripts than production ones. I tried to write a more complex bash script one time -- that met my expectations. W/o error testing the code was about 150 lines. With error testing and _helpful_ error messages it was over 1000. But that's the difference between quick&dirty vs. production. -e was useful for Q&D, IMO
Re: -e does not take effects in subshell
On 8/19/15 5:58 PM, Linda Walsh wrote: > > > Greg Wooledge wrote: >> >> (Wow, how did we get here from "-e does not take effects in subshell"?) >> > --- > because the POSIX spec changed and bash's handling of "-e" > changed to follow the new spec. This is true, though I would have used `revised' instead of `new'. > The earlier spec had -e only exit a script if a *simple* (external) > command failed. It didn't include builtins nor functions. This is not; builtins and functions are simple commands. The Posix spec changed because it didn't accurately reflect historical behavior. There was a *lot* of discussion about how to accurately describe the desired behavior, but everyone agreed that restricting it to simple commands was not how the `base implementations' behaved. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: quoted compound array assignment deprecated
On 8/18/15 5:05 PM, Dan Douglas wrote:
> Sorry I meant to reply to that thread but ran out of time. I think Stephane's
> eventual proposal was pretty close to what I had in mind but expressed badly.
> I'm not sure why it was eventually decided to deprecate the current system
> entirely but I'm not opposed to the idea - especially if it provides no
> functionality for which there aren't easy workarounds.
Deprecated doesn't mean removed. In this case, the meaning is closer to
discouraged or deemphasized.
Bash understands `declare' as a Posix declaration utility, and does its
best to treat arguments to declare and other declaration utilities
identically to standalone assignment statements. The place where that
breaks down is if a compound array assignment is treated as such by
declare when it would have been treated as a scalar assignment had it
appeared standalone. That's why the warning. It's not an error.
> The only thing I'm actively abusing this for at the moment in scripts I
> actually use is as a way of encoding 2D arrays. It's very much a read-only
> datastructure too.
>
> ~ $ ( key1=foo key2=bar; declare -A a=([foo]='([bar]=baz)') "b=${a[$key1]}"
> typeset -p a b; echo "${b[$key2]}" )
> declare -A a='([foo]="([bar]=baz)" )'
> declare -A b='([bar]="baz" )'
> baz
>
> Any change will likely break this property but I think wrapping it in eval
> gives the same result.
This will continue to work, but with a warning about a potentially
dangerous construct.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: -e does not take effects in subshell
On Tue, Aug 18, 2015 at 03:31:10PM -0700, Linda Walsh wrote: > with 'rm' functionality to remove '/' '.' and '..' was prohibited > by POSIX, though the coreutils version still allows the choice > of the more dangerous removal of '/' with with the --[no-]preserve-root. > > But the more useful "rm -fr ." [...] OK. I think you are saying that the POSIX specification sentence If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands. conflicts with your prior use of the GNU rm --one-file-system extension as a shorthand for "find . -xdev -delete". Since GNU already has a --no-preserve-root extension, as you pointed out, I don't see what would stop them from adding another extension to permit GNUrm -rfx . to work. Perhaps you should come up with an appropriate syntax for it and submit a patch to the GNU coreutils maintainers. This is not related to bash. (Wow, how did we get here from "-e does not take effects in subshell"?)
Re: remaking bash, trying static, glibc refuses static...?
Mike Frysinger wrote: On 18 Aug 2015 21:41, Linda Walsh wrote: Mike Frysinger wrote: On 18 Aug 2015 13:34, Linda Walsh wrote: (2) it's using the nss system which lets people drop modules into the system at anytime and change the overall lookups to use that. statically linking a specific subset would block that ability. --- The linux kernel is a perfect example of a statically linked program that can dynamically load plugins to provide authorization data from external sources. Static doesn't mean you can't support 3rd party plugins/libs -- like LDAP. which is what the current glibc code already does and why you get a warning when you link things staticlly. i'm not sure how you can argue both sides of the fence on this. -mike --- The current glibc code doesn't allow static linking (apart from a special static glibc build that I'd have to build myself). If the kernel can be linked statically, and yet load 3rd party plugins dynamically, why can't programs be linked statically with glibc (this usually pops up as an Error -- though that could be because many or most build procedures treat warnings as Errors). Also, you don't need a dynamic linker at run time to load plugins -- but glibc does because it patches addresses in the code to make direct calls into a dynamically loaded lib transparent. With the kernel it performs callouts to 'helpers' -- usually giving 1 key to a helper with the helper returning the associated value(s). It doesn't require dynamic linking -- but a helper script. Examples cifs.idmap (8) - Userspace helper for mapping ids for Common Internet F... cifs.upcall (8) - Userspace upcall helper for Common Internet File Syste... cifscreds (1)- manage NTLM credentials in kernel keyring getcifsacl (1) - Userspace helper to display an ACL in a security descr... idmapwb (8) - winbind ID mapping plugin for cifs-utils pam_cifscreds (8)- PAM module to manage NTLM credentials in kernel keyring setcifsacl (1) - Userspace helper to alter an ACL in a security descrip... None of those are required to be present when the kernel runs and the kernel doesn't die if something that would use one of those helpers is used but it isn't there. There are two types of dynamic linking... one where all libs must be present when the program loads, the other -- linux makes far too little use of. I got spoiled at SGI, as they used runtime dynamic linking to support different feature sets with different products. If you have an admin tool to add users, it might try to dlopen various independently offered products -- if they are not there, the program didn't show them on the menu -- it wasn't an error to have a dl-failure as it usually is w/glibc. Right now, if you try to load 'vim/gvim' on opensuse, you also have to have perl "libified" and openable at program invocation. You can't edit w/o the perl lib installed, but gvim doesn't require perl any more than it requires ruby, tcl or python that it can script with if such libs are present. If the libs are not present -- the core feature(s) of vim are still there -- you can edit. You may not be able to use alternate scripting languages while you edit, but you can at least start the editor and use it's standard features. W/glibc, if you wanted to do the same, you'd have it link and programs runnable with whatever was statically built in -- just like gvim -- if I don't have ruby/tcl/whatever installed, it says the language isn't available. glibc could return a list of available modules for a specific function and return soft-errors for missing components, with things like falling back to /etc/passwd &/| shadow being hard coded alternatives. But even if the dlopen call *can* be done right, I've yet to see a linux prog do it right and dynamically configure itself -- try an ldap auth w/no ldap plugin script? -- get a permission denied. glibc could use scriptable plugins like the kernel, but uses the more arcane dlopen for runtime loading -- that most projects get wrong -- and fall back to load-time (non-lazy) loading of dynamic libs. If you wanted to convince me glibc could be distributed statically, you could have it interface (as an example or proof of concept) with the userspace helpers the kernel uses for alternate authentication and permission mechanisms. But with the current mechanisms, if I'm not using NIS or LDAP, but "winbind" for login, I still need to have the NIS and LDAP libs available to run login. Right now it's like most progs require static linking at *load time*, which is the least flexible linking (programs don't auto-config "down" services that aren't available -- but you have to have all the kerberos and SASL, and every other possible security lib installed -- and that also allows separation of binaries and libraries to happen as people use symlinks in /bin/ls -> /usr/bin/ls when /usr isn't mounted and won't work without it's load-time dynamic libraries. Right no
Re: -e does not take effects in subshell
Greg Wooledge wrote: (Wow, how did we get here from "-e does not take effects in subshell"?) --- because the POSIX spec changed and bash's handling of "-e" changed to follow the new spec. The earlier spec had -e only exit a script if a *simple* (external) command failed. It didn't include builtins nor functions.
Re: assert built-in
On 8/19/15 11:48 AM, Greg Wooledge wrote:
> On Wed, Aug 19, 2015 at 08:39:15AM +, Craig wrote:
>> It's somewhat cumbersome to have to transport this assert function from
>> project to project, so it would save a considerable amount of effort and
>> time if it were built-in.
>
>> function assert() {
>> local lineno=${BASH_LINENO[0]} \
>> src=${BASH_SOURCE[1]} \
>> lines=()
>>
>> mapfile -n 1 -t -s $(( $lineno - 1 )) lines < "$src"
>>
>> printf "ASSERT: ${src##*/}:$lineno: %s\n" "$lines"
>>
>> exit 1
>> }
>
> I don't think there will be broad enough interest to justify bloating
> bash with a feature that can be achieved with a 4-line function.
I agree with this assessment, and note that this is the first request for
such a builtin. There's no indication that it's been generally requested.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: remaking bash, trying static, glibc refuses static...?
I sent this in response about 12 hours ago but haven't seen it come though on the list, so thought I'd resend it. Original Message Subject: Re: remaking bash, trying static, glibc refuses static...? Date: Wed, 19 Aug 2015 14:55:24 -0700 From: Linda Walsh <> To: bug-bash@gnu.org References: <55d106b2.9000...@tlinx.org> <20150817044932.GB1584@vapier> <55d396ef.8030...@tlinx.org> <20150819031852.GU1584@vapier> <55d408e4.9000...@tlinx.org> <20150819145815.GF1584@vapier> Mike Frysinger wrote: On 18 Aug 2015 21:41, Linda Walsh wrote: Mike Frysinger wrote: On 18 Aug 2015 13:34, Linda Walsh wrote: (2) it's using the nss system which lets people drop modules into the system at anytime and change the overall lookups to use that. statically linking a specific subset would block that ability. --- The linux kernel is a perfect example of a statically linked program that can dynamically load plugins to provide authorization data from external sources. Static doesn't mean you can't support 3rd party plugins/libs -- like LDAP. which is what the current glibc code already does and why you get a warning when you link things staticlly. i'm not sure how you can argue both sides of the fence on this. -mike --- The current glibc code doesn't allow static linking (apart from a special static glibc build that I'd have to build myself). If the kernel can be linked statically, and yet load 3rd party plugins dynamically, why can't programs be linked statically with glibc (this usually pops up as an Error -- though that could be because many or most build procedures treat warnings as Errors). Also, you don't need a dynamic linker at run time to load plugins -- but glibc does because it patches addresses in the code to make direct calls into a dynamically loaded lib transparent. With the kernel it performs callouts to 'helpers' -- usually giving 1 key to a helper with the helper returning the associated value(s). It doesn't require dynamic linking -- but a helper script. Examples cifs.idmap (8) - Userspace helper for mapping ids for Common Internet F... cifs.upcall (8) - Userspace upcall helper for Common Internet File Syste... cifscreds (1)- manage NTLM credentials in kernel keyring getcifsacl (1) - Userspace helper to display an ACL in a security descr... idmapwb (8) - winbind ID mapping plugin for cifs-utils pam_cifscreds (8)- PAM module to manage NTLM credentials in kernel keyring setcifsacl (1) - Userspace helper to alter an ACL in a security descrip... None of those are required to be present when the kernel runs and the kernel doesn't die if something that would use one of those helpers is used but it isn't there. There are two types of dynamic linking... one where all libs must be present when the program loads, the other -- linux makes far too little use of. I got spoiled at SGI, as they used runtime dynamic linking to support different feature sets with different products. If you have an admin tool to add users, it might try to dlopen various independently offered products -- if they are not there, the program didn't show them on the menu -- it wasn't an error to have a dl-failure as it usually is w/glibc. Right now, if you try to load 'vim/gvim' on opensuse, you also have to have perl "libified" and openable at program invocation. You can't edit w/o the perl lib installed, but gvim doesn't require perl any more than it requires ruby, tcl or python that it can script with if such libs are present. If the libs are not present -- the core feature(s) of vim are still there -- you can edit. You may not be able to use alternate scripting languages while you edit, but you can at least start the editor and use it's standard features. W/glibc, if you wanted to do the same, you'd have it link and programs runnable with whatever was statically built in -- just like gvim -- if I don't have ruby/tcl/whatever installed, it says the language isn't available. glibc could return a list of available modules for a specific function and return soft-errors for missing components, with things like falling back to /etc/passwd &/| shadow being hard coded alternatives. But even if the dlopen call *can* be done right, I've yet to see a linux prog do it right and dynamically configure itself -- try an ldap auth w/no ldap plugin script? -- get a permission denied. glibc could use scriptable plugins like the kernel, but uses the more arcane dlopen for runtime loading -- that most projects get wrong -- and fall back to load-time (non-lazy) loading of dynamic libs. If you wanted to convince me glibc could be distributed statically, you could have it interface (as an example or proof of concept) with the userspace helpers the kernel uses for alternate authentication and permission mechanisms. But with the current mechanisms, if I'm not using NIS or LDAP, but "winbind" for login, I still need to have the NIS and LDAP libs available t
