Alexander Bluhm writes:
> On Mon, Dec 26, 2016 at 09:08:22PM +0100, Jeremie Courreges-Anglas wrote:
>> Alexander Bluhm writes:
>> Your last diff has a drawback: you can't simply start the daemon like
>> this:
>>
>> # syslogd
>>
>> realpath will resolve "syslogd" to "/path/to/current/directory/
On Mon, Dec 26, 2016 at 09:08:22PM +0100, Jeremie Courreges-Anglas wrote:
> Alexander Bluhm writes:
> Your last diff has a drawback: you can't simply start the daemon like
> this:
>
> # syslogd
>
> realpath will resolve "syslogd" to "/path/to/current/directory/syslogd".
>
> Maybe call realpath
On Sun, Dec 25, 2016 at 09:47:16AM -0700, Todd C. Miller wrote:
> Another alternative is to use realpath(3) to resolve the path
> so it can be used after the chdir(2).
Good idea. I have moved all the path handling to privsep.c.
ok?
bluhm
Index: usr.sbin/syslogd/privsep.c
==
Another alternative is to use realpath(3) to resolve the path
so it can be used after the chdir(2).
- todd
On Fri, Dec 23, 2016 at 09:35:06PM -0700, Theo de Raadt wrote:
> This is why sshd has to be started with an absolute path, to
> avoid this problem. Path games like this worried us.
I doubt that it makes sense to require an absolute path for all our
daemons. It would break commands like 'pkill re
>When syslogd is started with a relative path, the reexec in the
>parent process fails. The chdir(2) should be done after execvp(3)
>in the parrent so that the same executable is found. Note that the
>child always does a chdir(2) after chroot(2).
>
>This allows to start ./syslogd which is useful
Hi,
When syslogd is started with a relative path, the reexec in the
parent process fails. The chdir(2) should be done after execvp(3)
in the parrent so that the same executable is found. Note that the
child always does a chdir(2) after chroot(2).
This allows to start ./syslogd which is useful f
