In <20000307130332.D6777@pcep-jamie.cern.ch> Jamie Lokier (lk@tantalophile.demon.co.uk) wrote:
> Khimenko Victor wrote:
>> > Because reading argv[0] is not a hack at all. The location of argv[0]
>> > will never change.
>>
>> Are you sure ?
> We can define it to be so :-)
No, we can not. argv[0] passed by execve system call can be different then
argv[0] as it's seen by user program. In case of ELF and "gcc" language they
are the same. But there are other languages exists, you know. Yes, you can
cut tonsils over asshole if you have enough skills. But why not provide more
natural way to do this if it's not hard ??
>> > There is no dubious overwriting of argument or environment string
>> > space, and no dubious limits are assumed or broken.
>> >
>> There just very strange limitation that program can change it's arguments
>> but can not change number of arguments...
> This is only for /proc/PID/cmdline. You only need 1 argument, though it
> is a convenient bonus that if you change argv[0] without clearing
> argv[1], you'll change the name of the program while keeping the
> existing arguments.
What I really WAHT is ability to remove some arguments from my command line.
Why ? Think about `mysql -P password` or other such things. Yes, you can just
replace password with 'x' or '*' but sometimes more convenient way is to just
remove password from argv array completely.
>> > > If program want to change argument list or environment list
>> > > then why notallow to do exactly this ?
>> >
>> > I can't think of any reason why a program needs to change its
>> > environment list.
>> >
>> Hmm. Your programs are doing this all the time. sh scripts, etc.
>> There are even few functions to do so (even POSIX ones!!!). Of course it's
>> not clear how important is to know if environment is changed. But if we
>> should not care about environment then why there are /proc/<number>/environ
>> at all ???
> I've always expected ps to show the environment that was passed to the
> program, not the current environment in the program. You make a good
> point though. /proc/PID/environ will not show either, because it reads
> from the program's environ string area which is like to be changed in a
> not very predictable manner by putenv.
Exactly :-) Look no further then your sendmail's /proc/PID/environ :-) It
was not result of putenv call but it's look strange, doesn't it ? At least
unsetenv can change it in VERY strange manner (AFAIK glibc's one will not do
anything harmfull to that area but even here I'm not sure).
>> > But an equally clean way, one that's convenient and AFAIK actually works
>> > on some other operating systems is to permit a program to say `argv[0] =
>> > "my new name";'.
>> >
>> AFAIK this way should work with my patch as well. It's just UGLY.
> Ok. So the syscall part of your patch is redundent then :-)
It's not redundant. Yes, with my patch you CAN do setproctitle(3) without
syscall in glibc and ONLY in glibc ! You need access to argv and you can access
it from glibc with changes in crt*.o or /lib/ld-linux.* (do we really want to
change THIS piece of glibc ???) and then you can change /proc/PID/cmdline
but you can not do other usefull things doable with proposed syscalls.
> btw, I can see now why you need some way for the change to envp by
> putenv to be passed to the kernel. Otherwise /proc/PID/environ is
> always wrong: it doesn't show the current environment and it doesn't
> show the unmodified one either. It potentially shows rubbish.
It REALLY shows rubbish in case of ftpd and sendmail :-) Of course without
proper changes in userspace it'll continue to show rubbish but it's other
story...
P.S. What's really important is to think more deep about names, parameters and
exact behaviour of proposed syscalls. Once they are in kernel it's not easy to
change anything.
P.P.S. BTW my patch still has old limitation: size of /proc/PID/cmdline and/or
/proc/PID/environ can not exceed 4KiB (PAGE_SIZE). It's just limitation of
changes in fs/proc/base.c, not limitation of proposed interface. It can be
fixed in future without userspace-visible changes...
P.P.P.S. Once again: why "big boys" are so silent on issue ? I know, it's not
very sexy but it SHOULD be done one way or another before 2.4 is out. Otherwise
you just can not do reliable ftpwho and on LOTS of sites such command is
usefull. It's easy to say that ftpd should not use setproctitle(3) for this
but then if it's all is not important then why procfs was invented in first
place ???
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST