about summary refs log tree commit diff
path: root/src/misc
Commit message (Collapse)AuthorAgeFilesLines
* make endmntent function handle null argumentTimo Teräs2014-08-081-1/+1
| | | | | The function originates from SunOS 4.x in which the null argument is allowed. glibc also handles this case.
* implement ffsl and ffsll functionsRich Felker2014-07-312-0/+14
| | | | | | per the resolution of Austin Group issue #617, these are accepted for XSI option in POSIX future and thus I'm treating them as standard functions.
* add issetugid function to check for elevated privilegeBrent Cook2014-07-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this function provides a way for third-party library code to use the same logic that's used internally in libc for suppressing untrusted input/state (e.g. the environment) when the application is running with privleges elevated by the setuid or setgid bit or some other mechanism. its semantics are intended to match the openbsd function by the same name. there was some question as to whether this function is necessary: getauxval(AT_SECURE) was proposed as an alternative. however, this has several drawbacks. the most obvious is that it asks programmers to be aware of an implementation detail of ELF-based systems (the aux vector) rather than simply the semantic predicate to be checked. and trying to write a safe, reliable version of issetugid in terms of getauxval is difficult. for example, early versions of the glibc getauxval did not report ENOENT, which could lead to false negatives if AT_SECURE was not present in the aux vector (this could probably only happen when running on non-linux kernels under linux emulation, since glibc does not support linux versions old enough to lack AT_SECURE). as for musl, getauxval has always properly reported errors, but prior to commit 7bece9c2095ee81f14b1088f6b0ba2f37fecb283, the musl implementation did not emulate AT_SECURE if missing, which would result in a false positive. since musl actually does partially support kernels that lack AT_SECURE, this was problematic. the intent is that library authors will use issetugid if its availability is detected at build time, and only fall back to the unreliable alternatives on systems that lack it. patch by Brent Cook. commit message/rationale by Rich Felker.
* provide getauxval(AT_SECURE) even if it is missing from the aux vectorRich Felker2014-07-171-0/+1
| | | | | | | | | | | | | this could happen on 2.4-series linux kernels that predate AT_SECURE and possibly on other kernels that are emulating the linux syscall API but not providing AT_SECURE in the aux vector at startup. in principle applications should be checking errno anyway, but this does not really work. to be secure, the caller would have to treat ENOENT (indeterminate result) as possibly-suid and thereby disable functionality in the typical non-suid usage case. and since glibc only runs on kernels that provide AT_SECURE, applications written to the glibc getauxval API might simply assume it succeeds.
* implement the LOG_CONS option in syslogRich Felker2014-07-111-1/+9
| | | | | | | this was previously a no-op, somewhat intentionally, because I failed to understand that it only has an effect when sending to the logging facility fails and thus is not the nuisance that it would be if always sent output to the console.
* suppress early syslog return when log socket cannot be openedRich Felker2014-07-111-4/+1
| | | | | | | this behavior is no longer valid in general, and was never necessary. if the LOG_PERROR option is set, output to stderr could still succeed. also, when the LOG_CONS option is added, it will need syslog to proceed even if opening the log socket fails.
* implement the LOG_PERROR option in syslogRich Felker2014-07-111-2/+4
| | | | | | | | | | | | | | this is a nonstandard feature, but easy and inexpensive to add. since the corresponding macro has always been defined in our syslog.h, it makes sense to actually support it. applications may reasonably be using the presence of the macro to assume that the feature is supported. the behavior of omitting the 'header' part of the log message does not seem to be well-documented, but matches other implementations (at least glibc) which have this option. based on a patch by Clément Vasseur, but simplified using %n.
* fix the %m specifier in syslogClément Vasseur2014-07-111-0/+3
| | | | | | errno must be saved upon vsyslog entry, otherwise its value could be changed by some libc function before reaching the %m handler in vsnprintf.
* implement fmtmsg functionRich Felker2014-06-211-0/+90
| | | | | contributed by Isaac Dunham. this seems to be the last interface that was missing for complete POSIX 2008 base + XSI coverage.
* support optional-argument extension to getopt via double-colonRich Felker2014-06-111-2/+5
| | | | | | | this extension is not incompatible with the standard behavior of the function, not expensive, and avoids requiring a replacement getopt with full GNU extensions for a few important apps including busybox's sed with the -i option.
* fix for broken kernel side RLIM_INFINITY on mipsSzabolcs Nagy2014-05-302-2/+18
| | | | | | | | | | | | | | | | | | | | On 32 bit mips the kernel uses -1UL/2 to mark RLIM_INFINITY (and this is the definition in the userspace api), but since it is in the middle of the valid range of limits and limits are often compared with relational operators, various kernel side logic is broken if larger than -1UL/2 limits are used. So we truncate the limits to -1UL/2 in get/setrlimit and prlimit. Even if the kernel side logic consistently treated -1UL/2 as greater than any other limit value, there wouldn't be any clean workaround that allowed using large limits: * using -1UL/2 as RLIM_INFINITY in userspace would mean different infinity value for get/setrlimt and prlimit (where infinity is always -1ULL) and userspace logic could break easily (just like the kernel is broken now) and more special case code would be needed for mips. * translating -1UL/2 kernel side value to -1ULL in userspace would mean that -1UL/2 limit cannot be set (eg. -1UL/2+1 had to be passed to the kernel instead).
* support kernels with no SYS_open syscall, only SYS_openatRich Felker2014-05-241-1/+1
| | | | | | | | | | open is handled specially because it is used from so many places, in so many variants (2 or 3 arguments, setting errno or not, and cancellable or not). trying to do it as a function would not only increase bloat, but would also risk subtle breakage. this is the first step towards supporting "new" archs where linux lacks "old" syscalls.
* add getauxval functionRich Felker2014-04-071-0/+12
| | | | | | | in a sense this implementation is incomplete since it doesn't provide the HWCAP_* macros for use with AT_HWCAP, which is perhaps the most important intended usage case for getauxval. they will be added at a later time.
* use syscall_arg_t for arguments in public syscall() functionRich Felker2014-03-181-7/+7
| | | | | | | on x32, this change allows programs which use syscall() with pointers or 64-bit values as arguments to work correctly, i.e. without truncation or incorrect sign extension. on all other supported archs, syscall_arg_t is defined as long, so this change is a no-op.
* fix negated error codes from ptsname_rRich Felker2014-03-171-1/+1
| | | | | | the incorrect error codes also made their way into errno when __ptsname_r was called by plain ptsname, which reports errors via errno rather than a return value.
* fix nftw FTW_MOUNT flagRich Felker2014-02-011-2/+1
| | | | | the incorrect check for crossing device boundaries was preventing nftw from traversing anything except the initially provided pathname.
* optimize get_current_dir_name to reduce stack bloatRich Felker2013-12-131-3/+1
| | | | | | | | our getcwd already (as an extension) supports allocation of a buffer when the buffer argument is a null pointer, so there's no need to duplicate the allocation logic in this wrapper function. duplicating it is actually harmful in that it doubles the stack usage from PATH_MAX to 2*PATH_MAX.
* include cleanups: remove unused headers and add feature test macrosSzabolcs Nagy2013-12-127-10/+3
|
* fix and refactor child reaping logic in wordexpRich Felker2013-11-221-6/+16
| | | | | | loop condition was incorrect and confusing and caused an infinite loop when (broken) applications reaped the pid from a signal handler or another thread before wordexp's call to waitpid could do so.
* fix fd leak and case where fd 1 is already closed in wordexpRich Felker2013-11-221-4/+4
|
* fix resource exhaustion and zero-word cases in wordexpRich Felker2013-11-221-8/+18
| | | | | | | | | | | | | when WRDE_NOSPACE is returned, the we_wordv and we_wordc members must be valid, because the interface contract allows them to return partial results. in the case of zero results (due either to resource exhaustion or a zero-word input) the we_wordv array still should contain a terminating null pointer and the initial we_offs null pointers. this is impossible on resource exhaustion, so a correct application must presumably check for a null pointer in we_wordv; POSIX however seems to ignore the issue. the previous code may have crashed under this situation.
* improve robustness of wordexp and fix handling of 0-word caseRich Felker2013-11-221-11/+16
| | | | | | | | | | | | | | | | | | | | avoid using exit status to determine if a shell error occurred, since broken programs may install SIGCHLD handlers which reap all zombies, including ones that don't belong to them. using clone and __WCLONE does not seem to work for avoiding this problem since exec resets the exit signal to SIGCHLD. instead, the new code uses a dummy word at the beginning of the shell's output, which is ignored, to determine whether the command was executed successfully. this also fixes a corner case where a word string containing zero words was interpreted as a single zero-length word rather than no words at all. POSIX does not seem to require this case to be supported anyway, though. in addition, the new code uses the correct retry idiom for waitpid to ensure that spurious STOP/CONT signals in the child and/or EINTR in the parent do not prevent successful wait for the child, and blocks signals in the child.
* remove incorrect cancellation points from realpathRich Felker2013-08-311-4/+4
|
* debloat realpath's allocation strategyRich Felker2013-08-311-12/+6
| | | | | | | | | rather than allocating a PATH_MAX-sized buffer when the caller does not provide an output buffer, work first with a PATH_MAX-sized temp buffer with automatic storage, and either copy it to the caller's buffer or strdup it on success. this not only avoids massive memory waste, but also avoids pulling in free (and thus the full malloc implementation) unnecessarily in static programs.
* make realpath use O_PATH when opening the fileRich Felker2013-08-311-1/+1
| | | | | | this avoids failure if the file is not readable and avoids odd behavior for device nodes, etc. on old kernels that lack O_PATH, the old behavior (O_RDONLY) will naturally happen as the fallback.
* debloat code that depends on /proc/self/fd/%d with shared functionRich Felker2013-08-021-1/+3
| | | | | | | I intend to add more Linux workarounds that depend on using these pathnames, and some of them will be in "syscall" functions that, from an anti-bloat standpoint, should not depend on the whole snprintf framework.
* Add ABI compatability aliases.Isaac Dunham2013-04-051-0/+2
| | | | | | | | GNU used several extensions that were incompatible with C99 and POSIX, so they used alternate names for the standard functions. The result is that we need these to run standards-conformant programs that were linked with glibc.
* fix typo in setpriority syscall wrapperRich Felker2013-04-011-1/+1
|
* fix multiple bugs in syslog interfacesRich Felker2013-03-231-24/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. as reported by William Haddon, the value returned by snprintf was wrongly used as a length passed to sendto, despite it possibly exceeding the buffer length. this could lead to invalid reads and leaking additional data to syslog. 2. openlog was storing a pointer to the ident string passed by the caller, rather than copying it. this bug is shared with (and even documented in) other implementations like glibc, but such behavior does not seem to meet the requirements of the standard. 3. extremely long ident provided to openlog, or corrupt ident due to the above issue, could possibly have resulted in buffer overflows. despite having the potential for smashing the stack, i believe the impact is low since ident points to a short string literal in typical application usage (and per the above bug, other usages will break horribly on other implementations). 4. when used with LOG_NDELAY, openlog was not connecting the newly-opened socket; sendto was being used instead. this defeated the main purpose of LOG_NDELAY: preparing for chroot. 5. the default facility was not being used at all, so all messages without an explicit facility passed to syslog were getting logged at the kernel facility. 6. setlogmask was not thread-safe; no synchronization was performed updating the mask. the fix uses atomics rather than locking to avoid introducing a lock in the fast path for messages whose priority is not in the mask. 7. in some code paths, the syslog lock was being unlocked twice; this could result in releasing a lock that was actually held by a different thread. some additional enhancements to syslog such as a default identifier based on argv[0] or similar may still be desired; at this time, only the above-listed bugs have been fixed.
* move new linux syscall wrapper functions to proper source dirRich Felker2012-12-072-16/+0
|
* fix trailing whitespace issues that crept in here and thereRich Felker2012-12-072-2/+2
|
* add arch_prctl syscall (amd64/x32 only)rofl0r2012-12-061-0/+9
|
* add personality syscallrofl0r2012-12-061-0/+7
|
* add getopt reset supportRich Felker2012-09-302-2/+18
| | | | | | | based on proposed patches by Daniel Cegiełka, with minor changes: - use a weak symbol for optreset so it doesn't clash with namespace - also reset optpos (position in multi-option arg like -lR) - also make getopt_long support reset
* fix some more O_CLOEXEC/SOCK_CLOEXEC issuesRich Felker2012-09-291-1/+1
|
* emulate SOCK_CLOEXEC and SOCK_NONBLOCK for old (pre-2.6.27) kernelsRich Felker2012-09-291-2/+1
| | | | | | | | | | | | | | | also update syslog to use SOCK_CLOEXEC rather than separate fcntl step, to make it safe in multithreaded programs that run external programs. emulation is not atomic; it could be made atomic by holding a lock on forking during the operation, but this seems like overkill. my goal is not to achieve perfect behavior on old kernels (which have plenty of other imperfect behavior already) but to avoid catastrophic breakage in (1) syslog, which would give no output on old kernels with the change to use SOCK_CLOEXEC, and (2) programs built on a new kernel where configure scripts detected a working SOCK_CLOEXEC, which later get run on older kernels (they may otherwise fail to work completely).
* fix dirname to handle input of form "foo/" correctlyRich Felker2012-09-261-6/+5
| | | | also optimized a bit.
* add setdomainname syscall, fix getdomainname (previously a stub)Rich Felker2012-09-092-1/+17
|
* cleanup src/linux and src/misc trees, etc.Rich Felker2012-09-0720-2697/+158
| | | | | | | | | | | | previously, it was pretty much random which one of these trees a given function appeared in. they have now been organized into: src/linux: non-POSIX linux syscalls (possibly shard with other nixen) src/legacy: various obsolete/legacy functions, mostly wrappers src/misc: still mostly uncategorized; some misc POSIX, some nonstd src/crypt: crypt hash functions further cleanup will be done later.
* fix constraint violation in ftwRich Felker2012-09-061-1/+4
| | | | void* does not implicitly convert to function pointer types.
* use restrict everywhere it's required by c99 and/or posix 2008Rich Felker2012-09-062-2/+2
| | | | | | | | to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
* fix missing statics in crypt_sha256 codeRich Felker2012-08-301-3/+3
|
* anti-DoS rounds count limits for blowfish and des cryptRich Felker2012-08-292-2/+2
| | | | | all of the limits could use review, but err on the side of avoiding excessive rounds for now.
* limit sha512 rounds to similar runtime to sha256 limitRich Felker2012-08-291-1/+1
| | | | | | | these limits could definitely use review, but for now, i feel consistency and erring on the side of preventing servers from getting bogged down by excessively-slow user-provided settings (think .htpasswd) are the best policy. blowfish should be updated to match.
* add sha256/sha512 cryptRich Felker2012-08-294-1/+700
| | | | | | | based on versions sent to the list by nsz, with some simplification and debloating. i'd still like to get them a bit smaller, or ideally merge them into a single file with most of the code being shared, but that can be done later.
* optimize legacy ffs functionRich Felker2012-08-231-4/+2
|
* add blowfish hash support to cryptRich Felker2012-08-103-8/+806
| | | | | | | there are still some discussions going on about tweaking the code, but at least thing brings us to the point of having something working in the repository. hopefully the remaining major hashes (md5,sha) will follow soon.
* make crypt return an unmatchable hash rather than NULL on failureRich Felker2012-08-091-5/+2
| | | | | | | | | | | | | | | | unfortunately, a large portion of programs which call crypt are not prepared for its failure and do not check that the return value is non-null before using it. thus, always "succeeding" but giving an unmatchable hash is reportedly a better behavior than failing on error. it was suggested that we could do this the same way as other implementations and put the null-to-unmatchable translation in the wrapper rather than the individual crypt modules like crypt_des, but when i tried to do it, i found it was making the logic in __crypt_r for keeping track of which hash type we're working with and whether it succeeded or failed much more complex, and potentially error-prone. the way i'm doing it now seems to have essentially zero cost, anyway.
* fix missing static in getusershell (namespace pollution)Rich Felker2012-08-021-1/+1
|
* replace old and ugly crypt implementationRich Felker2012-06-293-2574/+1055
| | | | | | | | | | | | | | | | | | | | | | | | | the new version is largely the work of Solar Designer, with minor changes for integration with musl. compared to the old code, text size is reduced by about 7k, stack space usage by about 70k, and performance is greatly improved by avoiding expensive calculation of constant tables on each run. this version also adds support for extended des-based password hashes, which allow for unlimited key (password) length and configurable iteration counts. i've also published the interface for crypt_r in a new crypt.h header. especially since this is not a standard interface, i did not feel compelled to match the glibc abi for the crypt_data structure. the glibc structure is way too big to allocate on the stack; in fact it's so big that the first usage may cause the main thread to exceed its pre-committed stack size of 128k and thus could cause the program to crash even on systems with overcommit disabled. the only legitimate use of crypt_data for crypt_r is to store the hash string to return, so i've reserved 256 bytes, which should be more than sufficient (longest known password hashes are ~60 characters, and beyond that is possibly even exceeding some implementations' passwd file field size limit).
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-02 23:17:18 +0000