| Age | Commit message (Collapse) | Author |
|---|
|
Use heap allocations instead. This avoids warnings:
```
../src/librc/librc.c: In function ‘rc_service_mark’:
../src/librc/librc.c:817:58: warning: ‘/’ directive output may be truncated writing 1 byte into a region of size between 0 and 4095 [-Wformat-truncation=]
817 | snprintf(was, sizeof(was), "%s/%s/%s",
| ^
../src/librc/librc.c:817:25: note: ‘snprintf’ output 3 or more bytes (assuming 4098) into a destination of size 4096
817 | snprintf(was, sizeof(was), "%s/%s/%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
818 | file, dir->value, base);
| ~~~~~~~~~~~~~~~~~~~~~~~
../src/librc/librc.c:822:58: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
822 | snprintf(was, sizeof(was), "%s/%s", file, dir->value);
| ^
../src/librc/librc.c:822:25: note: ‘snprintf’ output 2 or more bytes (assuming 4097) into a destination of size 4096
822 | snprintf(was, sizeof(was), "%s/%s", file, dir->value);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
|
|
Fixes the problem described in https://bugs.gentoo.org/916947 -
start-stop-daemon hangs in infinite loop when stopping some daemons on
linux 6.6+
It appears linux 6.6 reworked tmpfs, and since then it triggers this
problem in openrc: when iterating over files via readdir, running rename
on a file could result in reading the same file again with next readdir
call.
The Open Group manual for readdir explicitly states "If a file is
removed from or added to the directory after the most recent call to
opendir() or rewinddir(), whether a subsequent call to readdir() returns
an entry for that file is unspecified.". Linux man page don't seem to
mention that, but don't seem to say anything to contradict that either.
So I presume we can't rely on some specific behaviour here.
Bug: https://bugs.gentoo.org/916947
|
|
This was originally introduced in 14625346c07a2a66fe77ce578c9423918bec1d97 with
an example list (just one for rc_parallel) of options. Let's add in rc_interactive
as it's a pretty obvious thing one might want to override.
See https://forums.gentoo.org/viewtopic-p-8694588.html.
|
|
This conflicts with linux-headers which uses __unused for some padding members
on ppc64le at least.
Closes: https://github.com/OpenRC/openrc/issues/622
|
|
|
|
From scan-build w/ clang-16.0.0_pre20230107:
```
../src/librc/librc.c:759:14: warning: Potential leak of memory pointed to by 'init' [unix.Malloc]
return false;
^~~~~
```
|
|
Despite this being a 'deptree', it's actually
xmalloc'd in the same function (rc_deptree_update),
and so should be free'd, not rc_deptree_free'd,
as rc_deptree_load* wasn't used to allocate it.
```
[71/213] Compiling C object src/librc/librc.so.1.p/librc-depend.c.o
../src/librc/librc-depend.c: In function ‘rc_deptree_update’:
../src/librc/librc-depend.c:1077:9: warning: ‘rc_deptree_free’ called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
1077 | rc_deptree_free(deptree);
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/shared/misc.h:29,
from ../src/librc/librc.h:57,
from ../src/librc/librc-depend.c:21:
In function ‘xmalloc’,
inlined from ‘rc_deptree_update’ at ../src/librc/librc-depend.c:775:12:
../src/shared/helpers.h:64:23: note: returned from ‘malloc’
64 | void *value = malloc(size);
| ^~~~~~~~~~~~
```
This fixes #563.
|
|
|
|
(This is analogous to the rc_stringlist change.)
This gives a hint to the compiler that allocations (return values)
from this function should be paired with a corresponding dealloc/free
function.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This gives a hint to the compiler that allocations (return values)
from this function should be paired with a corresponding dealloc/free
function
In this case, it means that every rc_stringlist that rc_stringlist_new()
returns should eventually be freed by calling rc_stringlist_free(ptr)
where ptr is the relevant rc_stringlist.
We have to add a test for this into the build system
because only GCC supports this for now. In future, we might
be able to use meson's has_function_attribute (it does support
'malloc', just not AFAICT 'malloc with arguments').
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Both 'pkg' and 'local' are referenced within list,
so we can't free them yet.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
'services' is still referenced by the list
which gets returned. We can't free it.
Thanks to GCC 11's -fanalyzer.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Seen on running rc-status.
```
=================================================================
==14636==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 72 byte(s) in 3 object(s) allocated from:
#0 0x7f443412dcb7 in __interceptor_malloc /usr/src/debug/sys-devel/gcc-11.2.1_p20220312/gcc-11-20220312/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f443400c727 in xmalloc ../src/includes/helpers.h:64
#2 0x7f443400d1f4 in rc_stringlist_add ../src/librc/librc-stringlist.c:32
#3 0x7f4433fecc34 in get_runlevel_chain ../src/librc/librc.c:390
#4 0x7f4433fedc00 in rc_runlevel_stacks ../src/librc/librc.c:519
#5 0x7f4433ff1d8e in rc_services_in_runlevel_stacked ../src/librc/librc.c:976
#6 0x55be0e8f9517 in main ../src/rc/rc-status.c:407
#7 0x7f44334736cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This fixes #516.
|
|
- drop old build system
- move shared include and source files to common directory
- drop "rc-" prefix from shared include and source files
- move executable-specific code to individual directories under src
- adjust top-level .gitignore file for new build system
This closes #489.
|
|
|
|
There are no semantic changes in this commit.
Suggested-by: Mike Frysinger <vapier@gentoo.org>
See: https://github.com/OpenRC/openrc/pull/435#pullrequestreview-727035394
|
|
This makes the URIs shorter and dynamic: whatever the default branch
the repo uses will be used.
|
|
The existing copyright notices in the file headers cover these vars.
|
|
Fixes: #471
Fixes: #473
|
|
Fixes: #471
Fixes: #473
|
|
|
|
Closes #116.
Closes #171.
Closes #172.
Closes #175.
|
|
This function should return false if the runlevel is an empty string.
X-Gentoo-Bug: 803536
X-Gentoo-Bug-URL: https://bugs.gentoo.org/803536
Closes: https://github.com/OpenRC/openrc/pull/431
|
|
The previous fix excludes PIDs of processes running in a different namespace
regardless of whether the PID has been explicitly stored in a PID file mentioned
in the --pidfile parameter. The correct behavior is to only exclude the pid if
it is not stored in a pidfile.
X-Gentoo-Bug: 776010
X-Gentoo-Bug-URL: https://bugs.gentoo.org/776010
|
|
This fixes #313.
|
|
I am removing this on the advice of a member of the Gentoo toolchain
team. It was explained to me that this doesn't offer any significant
benefits to OpenRC.
If anyone ffeels differently, please open a pull request reverting
this and adding an explanation of what it does and how to know which
functions to mark hidden in the future.
This fixes #301.
|
|
This fixes #299.
|
|
This reverts commit 084877eb52971faf8f52c780ddd08ed9af140eb6.
The mentioned commit caused some systems to have some services reported
as crashed.
This fixes #297.
This fixes #298.
|
|
In some cases deptree or depinfo can be NULL, check
before dereferencing.
Fixes https://github.com/OpenRC/openrc/issues/293
Fixes https://github.com/OpenRC/openrc/pulls/294
X-Gentoo-Bug: 659906
X-Gentoo-Bug-URL: https://bugs.gentoo.org/659906
|
|
This fixes #226.
|
|
Clean up code indented with mixed tabs and spaces.
No actual code changes.
This fixes #280.
|
|
readlink(3) does not nul-terminate the result it sticks
into the supplied buffer. Consequently, the code
rc = readlink(path, buf, sizeof(buf));
does not necessarily produce a C string.
The code in rc_find_pid() produces some C strings this way
and passes them to strlen() and strcmp(), which can lead
to an out-of-bounds read.
In this case, since the code already takes care to
zero-initialize the buffers before passing them
to readlink(3), only allow sizeof(buf)-1 bytes to
be returned.
(While fixing this issue, I fixed two other locations that
used the same problematic pattern.)
This fixes #270.
|
|
The contents of /proc/<pid>/cmdline are read into
a stack buffer using
bytes = read(fd, buffer, sizeof(buffer));
followed by appending a null terminator to the buffer with
buffer[bytes] = '\0';
If bytes == sizeof(buffer), then this write is out-of-bounds.
Refactor the code to use rc_getfile instead, since PATH_MAX
is not the maximum size of /proc/<pid>/cmdline. (I hit this
issue in practice while compiling Linux; it tripped the
stack-smashing protector.)
This is roughly the same buffer overflow condition
that was fixed by commit 0ddee9b7d2b8dea810e252ca6a95c457876df120
This fixes #269.
|
|
|
|
Use errno != EACCES to fix false-positive for non-root users
with grsecurity kernels.
Fixes: 37e29442721a ("librc: Add check for crashed state")
This fixes #237
|
|
|
|
|
|
|
|
In rc_service_state,, call rc_service_daemons_crashed to check for
a crashed daemon if the service is started.
|
|
|
|
rc_deptree_update_needed would return early as soon as it found
any file newer than the existing dependency cache. Unfortunately,
the first file found may not be the newest one there; so the
clock skew workaround in rc-misc:_rc_deptree_load would be given
a timestamp that was still too old.
This fix forces a full scan of all relevant files, so as to
ensure that we return a timestamp that will allow the clock skew
fix to operate. The runtime cost is no worse than the case where
the cache is up to date (ie. we must check every possible file).
This fixes #161.
|
|
Ignore namespaces if there are errors reading either the pid namespace
for the current process or the process we aare testing.
This fixes https://github.com/openrc/openrc/issues/180.
|
|
This allows the equivalent of "unsetting" a value for a service.
|
|
X-Gentoo-Bug: 634634
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=634634
|
|
openrc-init.c and openrc-shutdown.c are based on code which was written by
James Hammons <jlhamm@acm.org>, so I would like to publically
thank him for his work.
|
|
X-Gentoo-Bug: 604666
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=604666
|
|
This fixes #109.
X-Gentoo-Bug: 558700
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558700
|
