Hi,
In the bad days of devfsd, no user program could remove /dev/stderr
(bacause fs didn't allow for that).
But I switched to udev sometime ago.
Today I discovered that my mysqld was happily unlinking it and
recreating as regular file in /dev (I pass --log=/dev/stderr
to mysqld).
Can I make /dev/stderr non-unlink-able?
--
vda
> Can I make /dev/stderr non-unlink-able?
Take a look to
$ man chattr
# chattr +i /dev/stderr
if you are using a ext2/3 filesystem. If not, maybe your filesystem has
some similar functionality.
--
Aurelien Degremont
> Hi,
>
> In the bad days of devfsd, no user program could remove /dev/stderr
> (bacause fs didn't allow for that).
>
> But I switched to udev sometime ago.
>
> Today I discovered that my mysqld was happily unlinking it and
> recreating as regular file in /dev (I pass --log=/dev/stderr
> to mysqld).
>
> Can I make /dev/stderr non-unlink-able?
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
You could run mysql as non-privileged user or try something like
--log=/proc/self/fd/2
-Christian
On Tuesday 14 March 2006 15:07, Aurelien Degremont wrote:
> > Can I make /dev/stderr non-unlink-able?
>
> Take a look to
>
> $ man chattr
> # chattr +i /dev/stderr
>
> if you are using a ext2/3 filesystem. If not, maybe your filesystem has
> some similar functionality.
I have ramfs based /dev, which I mount early over /dev (from initrd, in fact).
On-disk /dev/ is empty.
--
vda
On Tuesday 14 March 2006 15:11, Christian wrote:
> > Hi,
> >
> > In the bad days of devfsd, no user program could remove /dev/stderr
> > (bacause fs didn't allow for that).
> >
> > But I switched to udev sometime ago.
> >
> > Today I discovered that my mysqld was happily unlinking it and
> > recreating as regular file in /dev (I pass --log=/dev/stderr
> > to mysqld).
> >
> > Can I make /dev/stderr non-unlink-able?
> > --
> > vda
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> You could run mysql as non-privileged user or try something like
> --log=/proc/self/fd/2
Mysql people are strange. For example, their daemon does not want to die
on SIGTERM, this makes it harder to run it under daemontools.
Also it drops privileges BEFORE it opens logfiles (--log=xxx).
I cannot get it to log stuff on stderr:
echo "* Starting mysqld"
env - \
setuidgid root \
mysqld \
--defaults-file="$PWD/my.cnf" \
--user="$user" \
--datadir="$var/data" \
--tmpdir="$var/tmp" \
--socket="$PWD/mysql.socket" \
--pid-file="$PWD/mysql.pid" \
--skip-name-resolve \
--skip-innodb \
--skip-ndbcluster \
--skip-networking \
--log=/proc/self/fd/2 \
--log-slow-queries=/proc/self/fd/2 \
Those last two options don't work:
mysqld: File '/proc/self/fd/2' not found (Errcode: 13)
Oh well....
--
vda
On Tue, Mar 14, 2006 at 03:35:57PM +0200, Denis Vlasenko wrote:
> Mysql people are strange. For example, their daemon does not want to die
> on SIGTERM, this makes it harder to run it under daemontools.
Well, daemontools are equally strange ;-))
> Also it drops privileges BEFORE it opens logfiles (--log=xxx).
> I cannot get it to log stuff on stderr:
>
> echo "* Starting mysqld"
> env - \
> setuidgid root \
> mysqld \
> --defaults-file="$PWD/my.cnf" \
> --user="$user" \
> --datadir="$var/data" \
> --tmpdir="$var/tmp" \
> --socket="$PWD/mysql.socket" \
> --pid-file="$PWD/mysql.pid" \
> --skip-name-resolve \
> --skip-innodb \
> --skip-ndbcluster \
> --skip-networking \
> --log=/proc/self/fd/2 \
> --log-slow-queries=/proc/self/fd/2 \
>
> Those last two options don't work:
>
> mysqld: File '/proc/self/fd/2' not found (Errcode: 13)
any good daemon closes stdout, stderr, stdin and does chdir(/) on startup.
msqld might do so as well.
--
Stefan Seyfried \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, N?rnberg \ -- Leonard Cohen
Stefan Seyfried <[email protected]> writes:
> any good daemon closes stdout, stderr, stdin
A real good daemon would redirect them to /dev/null.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Wednesday 15 March 2006 13:02, Stefan Seyfried wrote:
> On Tue, Mar 14, 2006 at 03:35:57PM +0200, Denis Vlasenko wrote:
>
> > Mysql people are strange. For example, their daemon does not want to die
> > on SIGTERM, this makes it harder to run it under daemontools.
>
> Well, daemontools are equally strange ;-))
IMHO the most sane way to control zillions of background processes.
> > Also it drops privileges BEFORE it opens logfiles (--log=xxx).
> > I cannot get it to log stuff on stderr:
> >
> > echo "* Starting mysqld"
> > env - \
> > setuidgid root \
> > mysqld \
> > --defaults-file="$PWD/my.cnf" \
> > --user="$user" \
> > --datadir="$var/data" \
> > --tmpdir="$var/tmp" \
> > --socket="$PWD/mysql.socket" \
> > --pid-file="$PWD/mysql.pid" \
> > --skip-name-resolve \
> > --skip-innodb \
> > --skip-ndbcluster \
> > --skip-networking \
> > --log=/proc/self/fd/2 \
> > --log-slow-queries=/proc/self/fd/2 \
> >
> > Those last two options don't work:
> >
> > mysqld: File '/proc/self/fd/2' not found (Errcode: 13)
>
> any good daemon closes stdout, stderr, stdin and does chdir(/) on startup.
> msqld might do so as well.
No. Good daemon (e.g. apache does it) will open log file first, and _then_
will do setuid($user). Mysql tries to do it in opposite order, and (no wonder)
fails to open the log.
--
vda
On Wednesday 15 March 2006 15:14, Andreas Schwab wrote:
> Stefan Seyfried <[email protected]> writes:
>
> > any good daemon closes stdout, stderr, stdin
>
> A real good daemon would redirect them to /dev/null.
Yeah, yeah, let's first close stderr, and then proceed and
add some code to handle command line --log=file, and to do
logging to that file.
Why good ol' fprintf(stderr,...) isn't enough? Why do you
want to complicate things?
What's so hard in doing "daemon 2>/dev/null &" if you don't
want to save log?
--
vda
On Wed, 15 Mar 2006, Denis Vlasenko wrote:
> On Wednesday 15 March 2006 15:14, Andreas Schwab wrote:
>> Stefan Seyfried <[email protected]> writes:
>>
>>> any good daemon closes stdout, stderr, stdin
>>
>> A real good daemon would redirect them to /dev/null.
>
> Yeah, yeah, let's first close stderr, and then proceed and
> add some code to handle command line --log=file, and to do
> logging to that file.
>
> Why good ol' fprintf(stderr,...) isn't enough? Why do you
> want to complicate things?
>
> What's so hard in doing "daemon 2>/dev/null &" if you don't
> want to save log?
> --
> vda
The daemon needs to have the standard input closed as well as
any I/O connection to a possible terminal. Just closing
standard input, allows a dup() in rogue code to recreate it.
Basically, file-descriptors 0, 1, and 2, need to be USED and
used for something else (like open /dev/null or open "/").
That's how you prevent rogue code, inserted via overflow or
other means, from obtaining control of your system.
Good daemons also use system services to write messages to
log files. They don't make their own, which is one of the
reasons why early versions of `sendmail` were not considered
"good" daemons.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wednesday 15 March 2006 16:23, linux-os (Dick Johnson) wrote:
>
> On Wed, 15 Mar 2006, Denis Vlasenko wrote:
>
> > On Wednesday 15 March 2006 15:14, Andreas Schwab wrote:
> >> Stefan Seyfried <[email protected]> writes:
> >>
> >>> any good daemon closes stdout, stderr, stdin
> >>
> >> A real good daemon would redirect them to /dev/null.
> >
> > Yeah, yeah, let's first close stderr, and then proceed and
> > add some code to handle command line --log=file, and to do
> > logging to that file.
> >
> > Why good ol' fprintf(stderr,...) isn't enough? Why do you
> > want to complicate things?
> >
> > What's so hard in doing "daemon 2>/dev/null &" if you don't
> > want to save log?
> > --
> > vda
>
> The daemon needs to have the standard input closed as well as
> any I/O connection to a possible terminal. Just closing
> standard input, allows a dup() in rogue code to recreate it.
> Basically, file-descriptors 0, 1, and 2, need to be USED and
> used for something else (like open /dev/null or open "/").
> That's how you prevent rogue code, inserted via overflow or
> other means, from obtaining control of your system.
... and everything described above is perfectly doable by
shell mechanisms (like redirections) prior to strting daemon, right?
--
vda
>
>> any good daemon closes stdout, stderr, stdin
>
>A real good daemon would redirect them to /dev/null.
>
and writes to /var/log/mysql/...
Jan Engelhardt
--
On Thursday 16 March 2006 22:11, Jan Engelhardt wrote:
> >> any good daemon closes stdout, stderr, stdin
> >
> >A real good daemon would redirect them to /dev/null.
>
> and writes to /var/log/mysql/...
And has log rotation. Apache has log rotation. Squid has log rotation.
Why they all need to have log rotation code? I forced them all to just
write log to stderr, and multilog from daemontools does the logging
(with rotation and postprocessing (for example, feeds Squid log into
Mysql db)) just fine.
But we digress. Is there any magic (mount --bind?) to make
/dev/stderr undestructible?
--
vda
>> >> any good daemon closes stdout, stderr, stdin
>> >
>> >A real good daemon would redirect them to /dev/null.
>>
>> and writes to /var/log/mysql/...
>
>And has log rotation. Apache has log rotation. Squid has log rotation.
>
>Why they all need to have log rotation code? I forced them all to just
I dunno. SUSE Linux (no advertisement intended) uses a global solution -
"logrotate" rather than using each project's own logrotation.
>write log to stderr, and multilog from daemontools does the logging
>(with rotation and postprocessing (for example, feeds Squid log into
>Mysql db)) just fine.
>
>But we digress. Is there any magic (mount --bind?) to make
>/dev/stderr undestructible?
If not, you could write an LSM that prohibits unlinking /dev/stderr.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
On Fri, 17 Mar 2006, Jan Engelhardt wrote:
>>>>> any good daemon closes stdout, stderr, stdin
>>>>
>>>> A real good daemon would redirect them to /dev/null.
>>>
>>> and writes to /var/log/mysql/...
>>
>> And has log rotation. Apache has log rotation. Squid has log rotation.
>>
>> Why they all need to have log rotation code? I forced them all to just
>
> I dunno. SUSE Linux (no advertisement intended) uses a global solution -
> "logrotate" rather than using each project's own logrotation.
>
>> write log to stderr, and multilog from daemontools does the logging
>> (with rotation and postprocessing (for example, feeds Squid log into
>> Mysql db)) just fine.
>>
>> But we digress. Is there any magic (mount --bind?) to make
>> /dev/stderr undestructible?
>
> If not, you could write an LSM that prohibits unlinking /dev/stderr.
>
> Jan Engelhardt
That symlink isn't even used -- at least by any sane program!
I don't have a clue why these things were created and what they
were for. The objects stdin, stdout, and stderr, are 'C' runtime
library pointers to opaque types associated with the file descriptors,
STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO. The presence of
these bogus sym-links in /dev represent some kind of obfuscation
and have no value except to confuse (or identify a RedHat distribution).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) <[email protected]> wrote:
> On Fri, 17 Mar 2006, Jan Engelhardt wrote:
>> If not, you could write an LSM that prohibits unlinking /dev/stderr.
> That symlink isn't even used -- at least by any sane program!
> I don't have a clue why these things were created and what they
> were for. The objects stdin, stdout, and stderr, are 'C' runtime
> library pointers to opaque types associated with the file descriptors,
> STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO. The presence of
> these bogus sym-links in /dev represent some kind of obfuscation
> and have no value except to confuse (or identify a RedHat distribution).
Think about portable shell scripts. I remember /dev/std* longer than /proc.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On 3/18/06, Bodo Eggert <[email protected]> wrote:
> linux-os (Dick Johnson) <[email protected]> wrote:
> > On Fri, 17 Mar 2006, Jan Engelhardt wrote:
>
> >> If not, you could write an LSM that prohibits unlinking /dev/stderr.
>
> > That symlink isn't even used -- at least by any sane program!
> > I don't have a clue why these things were created and what they
> > were for. The objects stdin, stdout, and stderr, are 'C' runtime
> > library pointers to opaque types associated with the file descriptors,
> > STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO. The presence of
> > these bogus sym-links in /dev represent some kind of obfuscation
> > and have no value except to confuse (or identify a RedHat distribution).
>
> Think about portable shell scripts. I remember /dev/std* longer than /proc.
They're from BSD (where they are real devices, with a major & minor number).