Hi all :))
Finally, with a suitable solution at hand, I notice that the
kernel does just what I wanted to do, that is, overwriting the
argv[0]. The matter is that when executing the init process, the
kernel substitutes the program name, the true argv0, with the string
'init' :(( That is, I'm not able to exec'ing myself again, because I
no longer know what is the binary name!
How can I know, more or less portably, which is the name of the
disk binary corresponding to my core image? Since 'proc' is not
mounted at this time, I cannot consult my mappings not my 'exe'
link. Since this init is run as root, any that root can do is
welcome. Although I would like a portable solution, any solution that
works under *any* Linux kernel is welcome...
BTW, is the argv0 mangling for 'init' mandatory or POSIX or
standard or...?
Thanks a lot :)
Ra?l
> How can I know, more or less portably, which is the name of the
> disk binary corresponding to my core image? Since 'proc' is not
> mounted at this time, I cannot consult my mappings not my 'exe'
> link. Since this init is run as root, any that root can do is
> welcome. Although I would like a portable solution, any solution that
> works under *any* Linux kernel is welcome...
What about mounting /proc from inside your program? Not a big deal, easy
sollution ...
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]
Hi I?aki :)) (is that right?)
> > welcome. Although I would like a portable solution, any solution that
> > works under *any* Linux kernel is welcome...
> What about mounting /proc from inside your program? Not a big deal, easy
> sollution ...
I don't like it, because it should happen at the very beginning
of init. Remember, is not any program, is an init. Should be a more
clean way, I suppose :??
Ra?l
> > > welcome. Although I would like a portable solution, any
> solution that
> > > works under *any* Linux kernel is welcome...
> > What about mounting /proc from inside your program? Not a
> big deal, easy
> > sollution ...
>
> I don't like it, because it should happen at the very beginning
> of init. Remember, is not any program, is an init. Should be a more
> clean way, I suppose :??
I don't think is that big a deal ... if you startup the system normally,
sooner or later, /proc is going to be mounted. A [quickie] variation is:
mount()
get the info from /proc/self/whatever
umount()
Is simple, is clean and has no side effects; the code is pretty small, btw
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]
Hi I?aki :)
> > of init. Remember, is not any program, is an init. Should be a more
> > clean way, I suppose :??
> I don't think is that big a deal ... if you startup the system normally,
> sooner or later, /proc is going to be mounted. A [quickie] variation is:
Yes, I know, and that's one option, but I would like to avoid the
mounting. Not a big deal, anyway, as you say. The only thing is that
it won't work in kernels without proc enabled (yes, there are people
without 'proc', size issues, I suppose, etc...).
Thanks a lot :)
Ra?l
In article <20030115191942.GD47@DervishD>,
DervishD <[email protected]> wrote:
>> > of init. Remember, is not any program, is an init. Should be a more
>> > clean way, I suppose :??
>> I don't think is that big a deal ... if you startup the system normally,
>> sooner or later, /proc is going to be mounted. A [quickie] variation is:
>
> Yes, I know, and that's one option, but I would like to avoid the
>mounting. Not a big deal, anyway, as you say. The only thing is that
>it won't work in kernels without proc enabled (yes, there are people
>without 'proc', size issues, I suppose, etc...).
I assume that init is passed on the kernel command line like
init=/what/ever, right ?
Why not make that INIT=/what/ever, then make this /sbin/init:
main()
{
execl(getenv("INIT"), getenv("INIT"), "other", "args", NULL);
}
Kernel command line args not reckognized by the kernel get put
into the environment of init ..
Mike.
--
They all laughed when I said I wanted to build a joke-telling machine.
Well, I showed them! Nobody's laughing *now*! -- [email protected]
Hi Miquel :)
> Why not make that INIT=/what/ever, then make this /sbin/init:
I cannot force the users to do that :(( I think that I could
hardcode the name in the binary. The problem with this is that the
user may move around the binary afterwards...
I can't find a way to get the on-disk name from the core image
:(( Uff, this is getting way complicated, just for a pretty printing
of the proc titles.
Thanks for the suggestion, anyway :)) You're great.
Ra?l
DervishD <[email protected]>
[No attributions here, sorry]
> > > welcome. Although I would like a portable solution, any solution that
> > > works under *any* Linux kernel is welcome...
> > What about mounting /proc from inside your program? Not a big deal, easy
> > sollution ...
> I don't like it, because it should happen at the very beginning
> of init. Remember, is not any program, is an init. Should be a more
> clean way, I suppose :??
If it is init, you do have enough control over the environment to just
hardcode the executable's name?
In any case, I don't see what you want to acomplish here. Care to enligthen
us a bit?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Hi Horst :)
> > I don't like it, because it should happen at the very beginning
> > of init. Remember, is not any program, is an init. Should be a more
> > clean way, I suppose :??
> If it is init, you do have enough control over the environment to just
> hardcode the executable's name?
Yes, I can hardcode it, but I cannot avoid the admin moving
around or renaming the binary, so this is neither a solution :((
> In any case, I don't see what you want to acomplish here. Care to
> enligthen us a bit?
I've written a virtual-console-only init. Why this name and why I
coded it is a long story, but the matter is that it is an init that
doesn't need configuration (no /etc/inittab) and that has builtin
klogd, syslogd, getty and login. All the builtins are just forks, so
if you see at the ps output in a system running this, it will show
some instances of a process called 'init'. The first is an init,
true, but the second is the klogd emulator, the third is the slogd
emulator and all other are the gettylogin emulator.
That is, for clarity, those should be 'renamed'. I cannot rename
the binary, because all them are in the same binary. The only way is
mangling argv[0] in each fork, that's all. Currently, as I know for
the kernel sources that whatever the binary name argv[0] will contain
the string "init" (hope that it doesn't change in the future), I
overwrite it with 'klog', 'slog' and 'into', respectively for the
klogd emulator, the syslogd emulator and the gettylogin process. But
I would like to put more descriptive names. This is not an issue,
because I can go with those four letter names (that can reduced, more
or less meaningfully, to just one character) or even with all
processes called 'init'. The processes themselves doesn't rely on its
name for properly working. They do an openlog() in order to show
meaningful names in the system log.
That's what I want to do, and changing the names under argv[0]
seems to me as the proper solution. Anyway, it will released in a
week or so under GPL and I think that the code and documentation will
show a better (clearer, at least) picture.
Ra?l
On Wed, Jan 15, 2003 at 07:46:38PM +0000, Miquel van Smoorenburg wrote:
> In article <20030115191942.GD47@DervishD>,
> DervishD <[email protected]> wrote:
> >> > of init. Remember, is not any program, is an init. Should be a more
> >> > clean way, I suppose :??
> >> I don't think is that big a deal ... if you startup the system normally,
> >> sooner or later, /proc is going to be mounted. A [quickie] variation is:
> >
> > Yes, I know, and that's one option, but I would like to avoid the
> >mounting. Not a big deal, anyway, as you say. The only thing is that
> >it won't work in kernels without proc enabled (yes, there are people
> >without 'proc', size issues, I suppose, etc...).
>
> I assume that init is passed on the kernel command line like
> init=/what/ever, right ?
>
> Why not make that INIT=/what/ever, then make this /sbin/init:
Why not make a kernel patch that sets the INIT environment variable for
the init process ?
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
On Thu, Jan 16, 2003 at 12:27:45PM +0100, DervishD wrote:
> That is, for clarity, those should be 'renamed'. I cannot rename
> the binary, because all them are in the same binary. The only way is
> mangling argv[0] in each fork, that's all. Currently, as I know for
ln init klogd
ln init slog
ln init into
main (...)
{
if (strstr (argv[0], "klogd"))
go_do_klogd ();
...
This is similar to what busybox uses.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
Hi Jakob :))
> > I assume that init is passed on the kernel command line like
> > init=/what/ever, right ?
> > Why not make that INIT=/what/ever, then make this /sbin/init:
> Why not make a kernel patch that sets the INIT environment variable for
> the init process ?
Doesn't worth it, just for reexec'ing init and be able to mangle
with argv[0], which isn't a good thing, anyway ;)
Ra?l
Hi Horst :)
> > some instances of a process called 'init'. The first is an init,
> > true, but the second is the klogd emulator, the third is the slogd
> > emulator and all other are the gettylogin emulator.
> Something like nash that RH uses on their initrd (it is sh, and modprobe,
> and mount, and ...; so they save on libc and random boilerplate code which
> is only once on the disk), or like a package called swish (or something
> like that), that is a shell which has ls, rm, ... builtin?
I'm afraid that those use symlinks or hardlinks to run every
different personality. What my init does is more or less (no real
code):
pid=fork();
if (!pid) do_klog();
...
pid=fork();
if (!pid) do_slog();
So, in function do_klog() we would like to change argv[0]. Things
like busybox and the like uses symlinks or mechanisms like 'command
subcommand'.
I'll give a look at the microdistros, anyway :)) Thanks :)
Ra?l
Hi Rogier :)
> ln init klogd
> ln init slog
> ln init into
Won't work, we fork, don't exec. I will need to rewrite a lot of
code just for converting the fork-scheme to a fork+exec-scheme.
Moreover, this will introduce vulnerabilities... It's not safe from
init to just exec 'klogd'. It will need full paths.
Thanks for answering :)
Ra?l