Take a look in /var/run. Find a pid file that is owned by a non-root
user. Now, look at the corresponding init script. What does it stop if
that non-root user edited the pid file to contain '1'?
I surveyed 20-odd daemons, and found 5 with this problem. This is
a pity, because start-stop-daemon has
On mar., 2010-05-04 at 02:25 -0400, Joey Hess wrote:
> As security problems go, being able to DOS a system by killing targeted
> processes, slowly, is not very bad. After all, it could be fork bombed
> or OOMed just as effectively. Security aside, there's an overall correctness
> issue: There's the
Yves-Alexis Perez a écrit :
> And you usually need root access for invoke-rc.d or /etc/init.d scripts
> (unless you have some kind of specific sudo permissions for that). So
> you might be able to kill other process as well.
I guess one (be it a human operator or a monit-like daemon) can be
easily
On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?
The fact that they are not owned by root doesn't
On 2010-05-04, Salvo Tomaselli wrote:
> On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
>> Take a look in /var/run. Find a pid file that is owned by a non-root
>> user. Now, look at the corresponding init script. What does it stop if
>> that non-root user edited the pid file to contain '1'?
> The
On Tue, May 04, 2010 at 02:25:25AM -0400, Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?
On Linux, nothing. From kill(2):
T
On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> Nevertheless, this could be a problem with other pids or on kfreebsd,
> where the kernel will happily kill init and cause a panic.
And the pid could still be set to something else than 1 and bring down
something important.
--
Salvo Tomase
On Tue, May 04, 2010 at 07:02:23PM +0200, Salvo Tomaselli wrote:
> On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> > Nevertheless, this could be a problem with other pids or on kfreebsd,
> > where the kernel will happily kill init and cause a panic.
> And the pid could still be set to som
Stéphane Glondu writes:
> Yves-Alexis Perez a écrit :
>> And you usually need root access for invoke-rc.d or /etc/init.d scripts
>> (unless you have some kind of specific sudo permissions for that). So
>> you might be able to kill other process as well.
>
> I guess one (be it a human operator o
apologies for butting-in without being able to continue the thread,
but i've just seen this:
http://advogato.org/person/etbe/diary/779.html
which links to this:
http://lists.debian.org/debian-devel/2010/05/msg00067.html
can i please gently remind people that depinit solved the security and
fork-bo
On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton
wrote:
> apologies for butting-in without being able to continue the thread,
> but i've just seen this:
> http://advogato.org/person/etbe/diary/779.html
> which links to this:
> http://lists.debian.org/debian-devel/2010/05/msg00067.html
http://etb
]] Russell Coker
| > in other words, a service is _always_ run
| > in "foreground" mode. if it dies (i.e. a segfault signal is caught),
| > the service is restarted automatically - by depinit (based on the
| > signal alone). thus, the need for safe_mysql goes away entirely; the
| > need for "ap
On Sat, Jun 5, 2010 at 2:26 AM, Russell Coker wrote:
> On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton
> wrote:
>> apologies for butting-in without being able to continue the thread,
>> but i've just seen this:
>> http://advogato.org/person/etbe/diary/779.html
>> which links to this:
>> http://l
]] Luke Kenneth Casson Leighton
| > Does a program that uses inotify to wait for log file changes on disk
| > experience any delay of note?
|
| ... no - you're right: it wouldn't. so that would be a solution
| but again, it would require an application that had that capability
| [to use no
On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton
wrote:
> okaaay, riight. so. ah ha. it makes things quicker... by avoiding
> starting the services _entirely_ :)
It goes beyond that. Instead of program A depending on B being done
initializing so that it can connect to B's socket,
15 matches
Mail list logo
