Linux-Development-Sys Digest #74, Volume #7 Fri, 20 Aug 99 00:14:18 EDT
Contents:
Re: Code for security: chroot and child processes (Dave Platt)
Re: Code for security: chroot and child processes (brian moore)
Linux on embedded systems: question on memory footprint (Marco Zandonadi)
Re: GUI apps core dumping on printf's (Dimi Shahbaz)
Re: Why so inefficient source RPM's ?? (Christopher Browne)
Re: Code for security: chroot and child processes (brian moore)
Re: most efficient way to zero out a partition? (Christopher Browne)
Re: Question about segments (Bartosz Klimek)
Re: Calling a BIOS interrupt (Bartosz Klimek)
where's the source to init (Eric Hegstrom)
MMX programming ("giacomo")
Re: Code for security: chroot and child processes (brian moore)
Re: Help!! LILO booting stopping on LI (Horst von Brand)
Having a problem loggin in, need help ("Advanced one corporation")
Re: More kind words from M$. (Kaz Kylheku)
Having a problem loggin in, need help ("Advanced one corporation")
RedHat 5.1 / 5.2 / 6.0 - development queries (babu krishnamurthy)
Re: naive newbie wants to call add_timer() (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Subject: Re: Code for security: chroot and child processes
Date: Fri, 20 Aug 1999 00:02:51 GMT
In article <[EMAIL PROTECTED]>,
brian moore <[EMAIL PROTECTED]> wrote:
>mkdir("backdoor");
>chroot("backdoor");
>chdir("..");
After a chroot() call, the ".." link in the new root-jail directory
points back to that same directory - _not_ to the "true" ancestor of
the directory.
At least, this was the case the last time I tried it. If this were
not the case, chroot() would be fundamentally useless... and I rather
doubt that so obvious a goof would have been missed by the folks who
designed it.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Subject: Re: Code for security: chroot and child processes
Date: 19 Aug 1999 23:14:21 GMT
On Tue, 17 Aug 1999 21:01:49 GMT,
NICHOLAS DRONEN <[EMAIL PROTECTED]> wrote:
> brian moore ([EMAIL PROTECTED]) wrote:
> : On 12 Aug 1999 02:01:12 GMT,
> : Mike Khalili <[EMAIL PROTECTED]> wrote:
> : > On Wed, 11 Aug 1999 16:59:14 -0700, Sean O'Dell <[EMAIL PROTECTED]> wrote:
> : > >Thank you for your help! It works great, but now I've run into something
> : > >else I'm not sure about. When the program is run, I use seteuid to change
> : > >the uid of the process to the uid of the owner of the file interpreted by
> : > >the program, for security reasons. I also chroot to the user's home
> : > >directory, just for further safety. However, there are some functions to
> : > >the program which I need to seteuid back to root and also see the file
> : > >system hierarchy above where I chroot'ed (just temporarily). I haven't
> : > >figured out how to "undo" the chroot...is it possible?
> : >
> : > No, it is not. Once you chroot() you're stuck with it.
>
> : Not entirely true. There are ways to get out of a chroot jail.
>
> Perhaps you should explain how this is done.
Easy way?
mkdir("backdoor");
chroot("backdoor");
chdir("..");
Which of course means that for root (ie, the only one able to change
uid's at will as the original poster needed), chroot is meaningless:
it's trivial to escape with the above method.
And... since it's trivial to escape, it's pointless to chroot() as a
'security' measure in this case.
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
From: Marco Zandonadi <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.help
Subject: Linux on embedded systems: question on memory footprint
Date: Thu, 19 Aug 1999 17:20:31 -0700
Hello,
I'm considering using Linux in an embedded system project.
I compiled the following trivial program on a Redhat 6.0 distribution
using "egcs -O3 test.c".
#include <unistd.h>
int main ()
{
sleep(5);
return 1;
}
I ran the program and did a "ps auex" to check memory consumption.
According to ps, a.out uses the following amount of memory:
VSZ 1048
RSS 260
Unfortunately both of them are too high for embedded applications. Now
the questions are:
1) Why is memory consumption so big for such a simple program?
2) Is there a way to reduce this problem?
3) Does the kernel configuration incide on the size of programs in
memory?
Thanks a lot for any help! Please answer via e-mail because I cannot
check these groups regularly.
Marco Zandonadi
------------------------------
From: Dimi Shahbaz <[EMAIL PROTECTED]>
Crossposted-To: comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: Re: GUI apps core dumping on printf's
Date: Thu, 19 Aug 1999 18:24:56 -0700
Kaz Kylheku wrote:
> On Wed, 18 Aug 1999 11:29:12 -0700, Dimi Shahbaz <[EMAIL PROTECTED]>
> wrote:
> >Hello,
> >When developing GUI apps (using KDE &qt) I like to put printf's and
> >cout's in the code for debugging purposes. This use to work fine, and I
> >saw the printf's in the app's parent terminal. Now, however, the GUI
> >program core dumps if it printf's more than 1 newline to the parent
> >terminal. Ie, if I printf("debug message\n something else\n"); I see
> >the "debug message" printed ok, but the second line doesn't show up,
> >and the program seg faults.
>
> You do realize that the first argument to printf is actually a format
> string that is scanned for conversion specifiers? Check that there
> are no conversion specifiers in the text you are trying to print.
> If it cannot be determined at compile time that there are no conversion
> specifiers, maybe you should use some other function, like fputs().
>
> Show the exact message you are trying to print.
There are no conversion specifiers in my printf's. They are just statements
like:
printf("here \n there \n");
(I get the same core dumps with cout's that contain more than one newline as well
as well).
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Aug 1999 00:52:20 GMT
On 19 Aug 1999 08:18:34 +0200, Peter Mutsaers <[EMAIL PROTECTED]> wrote:
>>> "JK" == Johan Kullstam <[EMAIL PROTECTED]> writes:
>
> JK> what if the builder doesn't offer a patch. you want to roll up a new
> JK> rpm from the newer sources and wish to borrow from past rpm spec
> JK> files. you have to download the source twice. it's annoying.
>
> JK> i want a no-source rpm. i want the source-less rpms to be found on
> JK> ftp sites. the application maintainer cannot change this situation
> JK> one way or another. (unless you are talking about the maintainer of
> JK> the rpm application only.)
>
>Indeed, that's just what I meant. I'm just surprised that no-source
>rpm's aren't standard.
Are you sure that's what you meant to say?
>And the no-source RPM should also (in the spec-file) give a list of
>URL's where the original tarball can be found. Then it can be
>retrieved automatically if necessary, and stored in a cache
>directory. This is more or less how FreeBSD works: the first time you
>build a port the tarball is put in /usr/ports/distfiles, subsequent
>times (assuming the port is still based on the same original release)
>the tarball from /usr/ports/distfiles is automatically reused.
The problem is that there are two behaviours:
a) A further patch was needed to fix some odd behaviour with a
package, thereby bumping up the "most-minor" version number, but not
requiring any new "pristine sources."
That would be a case where all that really needs to be transmitted
around is the patch file.
More common appears to be...
b) The "pristine sources" changed, mandating a new version number (and
not merely because we updated the RPM).
In this case, the whole tarball is needed.
There seems to be reasonably widespread agreement that RPM isn't the
best possible system that one might conceive of; I'm not convinced
that the situation being described represents a real good example of
"major problems with RPM."
--
"When we understand knowledge-based systems, it will be as before
-- except our fingertips will have been singed." -- Alan Perlis
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Subject: Re: Code for security: chroot and child processes
Date: 20 Aug 1999 01:26:10 GMT
On Fri, 20 Aug 1999 00:02:51 GMT,
Dave Platt <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> brian moore <[EMAIL PROTECTED]> wrote:
>
> >mkdir("backdoor");
> >chroot("backdoor");
> >chdir("..");
>
> After a chroot() call, the ".." link in the new root-jail directory
> points back to that same directory - _not_ to the "true" ancestor of
> the directory.
Sure, but what is the current directory at that point?
>From the chroot(2) man page:
Note that this call does not change the current working
directory, so that `.' can be outside the tree rooted at
`/'.
So now ".." is out of the old chrooted jail... and "../../../.."
repeated enough is going to be /. You could loop it until . equals ..
and find the real root that way if you want.
> At least, this was the case the last time I tried it. If this were
> not the case, chroot() would be fundamentally useless... and I rather
> doubt that so obvious a goof would have been missed by the folks who
> designed it.
Then you didn't try it right.
chroot() is useful: it's just not a panacea. root can easily escape a
chroot jail. (Why do you think only root can chroot? If anyone could,
then chroot -would- be useless.)
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: most efficient way to zero out a partition?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Aug 1999 01:28:13 GMT
On 19 Aug 1999 12:45:13 -0700, Ronald Cole <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (H. Peter Anvin) writes:
>> Using "cat" is probably somewhat faster than "dd"... however, covering
>> the entire disk surface is what takes most of the time.
>
>If the kernel can optimize the buffering for the devices, then cat it
>is. I discovered that dd with any blocksize greater than the default
>locks up RedHat's linux-2.2.5-22smp.
That's not a good reason to use cat; there's a Very Bad Bug there
someplace...
--
"When we understand knowledge-based systems, it will be as before
-- except our fingertips will have been singed." -- Alan Perlis
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Bartosz Klimek <[EMAIL PROTECTED]>
Subject: Re: Question about segments
Date: Fri, 20 Aug 1999 01:38:07 GMT
"Erwin S. Andreasen" wrote:
>
> On Thu, 19 Aug 1999 11:46:30 GMT, Bartosz Klimek wrote:
>
> >There's something I don't understand about process segments. I suppose
> >every process in Linux has a code segment, data segment, const data
> >segment, stack segment. And now, if I have a pointer, e.g. char *p, it
> >is a 32b offset. Look at this:
>
> Nope, everything looks like just a one big 32-bit address space to the user
> process (and this flat address space is true for just about all Unices I
> think). Some of that virtual address space is then mapped to physical pages,
> but the processes know nothing about that and don't really care whether this
> page really resides in memory or in swap.
>
> Data, text, constants are page of the virtual address space which have
> different protection. For example the code segment is mapped
> read-only/executable from a file and thus automatically shared between
> several copies of that same program running.
>
Thanks for explanation.
So all such things like read-only protection (const data) and automatic
resizing of the stack is done at the page level?
Hope you are patient enough to read some more questions of mine :)
Take a look at this code:
void f() {
/*...*/
char c[] = "xxxxx";
char *p;
c[0] = 1; /* (1) */
Line (1) is assembled to this:
movb $0x1,0xfffffff8(%ebp)
This instruction uses ss segment register (I know, I know, ss is not an
adress, it points to a descriptor).
Now, we do the following:
p = c;
leal 0xfffffff8(%ebp),%ecx
movl %ecx,0xfffffff4(%ebp)
p contains offset relative to the start of the segment pointed to by the
descriptor pointed to by ss. Is it so?
And then:
p[0] = 1; /* equivalent to c[0] = 1 */
movl 0xfffffff4(%ebp),%eax
movb $0x1,(%eax)
The offset in p goes to eax. The second of the above instructions uses
ds segment register. My conclusion is that ds = ss. Is it right?
All these questions came to my mind when I was reading a book on i486
processor. At first I thought: what a beautiful world. We have cs, ds,
ss, es, so we can make distinct segments for different kind of data,
each of them managed in a different way, each of them with different
protections. When I was already happy, I asked myself: OK, but in C we
have completely flat pointers! So how can we reach different segments?
OK, so there's only one segment. But then, instructions do use different
segment registers. pushl uses ss, movl usually uses ds. And at this
point I got stuck.
> Stack is slightly special, since it has to automatically grown downwards.
> AFAIR the kernel traps illegal access (i.e. access to a virtual address
> which is not mapped) and if that would fall within the stack's size, it
> expands the stack accordingly.
All right, but if the space is so pefectly flat, how does the kernel
know if we want to access stack or non-stack?
What a mess in my mind... I'd rather go to bed... But it's going to be a
sleepless night. Maybe I should be a philosopher not a philolinuxer.
--
Bartosz Klimek
mailto:[EMAIL PROTECTED]
------------------------------
From: Bartosz Klimek <[EMAIL PROTECTED]>
Subject: Re: Calling a BIOS interrupt
Date: Fri, 20 Aug 1999 01:38:05 GMT
Chris Butler wrote:
>
> > I heard that Linux saves informations of the BIOS at boottime.
> > Is this true or not?
>
> It gets all the information it needs from the BIOS at boot time (eg, HD
> information, etc), before switching to protected mode.
Are you sure about that HD information? I think the kernel ignores what
BIOS says about HD. I once used to change disk drives without setting
BIOS appropriately, and Linux somehow identified disk geometry etc.
Best regards,
--
Bartosz Klimek
mailto:[EMAIL PROTECTED]
------------------------------
From: Eric Hegstrom <[EMAIL PROTECTED]>
Subject: where's the source to init
Date: Thu, 19 Aug 1999 18:54:50 -0700
OK I feel like an idiot.
I know the source to /sbin/init is somewhere on the second redhat disk
but which package is it in. Is there an easy way to answer these
questions myself.
Cheers,
Linux
--
Eric Hegstrom .~.
Senior Software Engineer /V\
Sonoran Scanners, Inc. // \\ L I N U X
[EMAIL PROTECTED] /( )\ >don't fear the penguin<
520-617-0072 x402 ^^-^^
Sorry I haven't determined the ICBM address here yet...
------------------------------
From: "giacomo" <[EMAIL PROTECTED]>
Subject: MMX programming
Date: Fri, 20 Aug 1999 03:54:39 +0200
I need to use MMX assembly code into my C code,
I must use _byte( 0xbla, 0xbla, 0xbla ) statement in gcc environment or
there are more simple solution?
thanks
Jak
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.security,comp.os.linux.development.apps
Subject: Re: Code for security: chroot and child processes
Date: 20 Aug 1999 02:41:00 GMT
On 17 Aug 1999 22:20:27 +0100,
Chris Butler <[EMAIL PROTECTED]> wrote:
> [comp.os.linux.development.apps - 17 Aug 1999 18:35:26 GMT] * brian wrote *
> > On 12 Aug 1999 02:01:12 GMT,
> > Mike Khalili <[EMAIL PROTECTED]> wrote:
> >> No, it is not. Once you chroot() you're stuck with it.
> > Not entirely true. There are ways to get out of a chroot jail.
>
> Only if you're still running as root. Since apps that chroot normally set
> their UID to something other than root, this is unlikely.
Then do go back and read the thread. The question did involve a suid
root process living in a chroot jail.
For root, chroot is just a minor annoyance and is trivial to escape via
several mechanisms. (The mkdir()/chroot()/chdir() trick is just the
easiest, you can also do fun things like load kernel modules, remount
file systems, etc...)
Letting root into the jail makes the whole thing pointless.
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
From: [EMAIL PROTECTED] (Horst von Brand)
Subject: Re: Help!! LILO booting stopping on LI
Date: 20 Aug 1999 02:22:34 GMT
On 19 Aug 1999 16:02:27 -0700, Ronald Cole <[EMAIL PROTECTED]> wrote:
>Madhu Bandireddi <[EMAIL PROTECTED]> writes:
>> I have Redhat 6.0 installed on Pentium with Adaptec 2940 SCSI and SCSI
>> disks. The system was working fine...booting
>> from hard disk until I messed it up. I tried to upgrade the Kernel to
>> 2.2.11 from 2.2.5-15. I compiled the new kernel
>> and moved it /boot as vmlinux and then edited /etc/lilo.conf and ran
>> lilo. Eversince I did whenever I reboot it hangs on the
>> way up at the lilo prompt with just "LI" printed on the screen. I
>> reverted back to the original lilo.conf and repointed the links under
>> /boot to the old 2.2.5-15 files and ran lilo again. But I am still not
>> able to boot from the hard disk.
LI means the geometry lilo is seeing doesn't agree with what the kernel
knows. Try using the "linear" option, or redefining your disk (LBA, LARGE,
etc) via BIOS settings.
>> root=/dev/sda8
>> Can someone help me out of ignorance here?
>I'll bet that you installed the bootstrap loader on /dev/sda8 and that
>your /dev/sda8 starts over the 1024 cylinder limit.
Then lilo would have complained when it was run. Almost for sure.
Hope this helps somewhat.
PS: 2.2.11 has a known bug that eats memory with certain network setups.
Wait for 2.2.12 (should be out very soon), it is fixed there.
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vi�a del Mar, Chile +56 32 672616
------------------------------
From: "Advanced one corporation" <[EMAIL PROTECTED]>
Subject: Having a problem loggin in, need help
Date: Thu, 19 Aug 1999 23:17:29 +0100
I'm having a problem loggin in. After I have logged in to my localhost by
typing in root and then my password, this message appears:
[root@localhost /root#
What does this message mean and what do I type.
Help is appreciated.
Thanks
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: Fri, 20 Aug 1999 02:30:32 GMT
On Thu, 19 Aug 1999 22:13:46 -0400, Charles Sullivan <[EMAIL PROTECTED]>
wrote:
>
>Mindspring News wrote in message <7pdve2$6in$[EMAIL PROTECTED]>...
>>
>>He's just an AOL employee posing as a microsoft developer to further AOL's
>>insidious purposes. He used the words "unpleasantly" and "experienced". A
>>real microsoft programmer can't use words more than 8 letters in length ;)
>
>Hah! I like that.
He can cheat by dropping a few vowels and using a three letter extension.
If he or she has space left over, they might even throw in the digits
'32'. Thus
unpleasantly
can be quite succinctly expressed as
unplsn32.tly
The 32 is needed as reassurance that this isn't 16 bit DOS or Windows anymore.
:)
------------------------------
From: "Advanced one corporation" <[EMAIL PROTECTED]>
Subject: Having a problem loggin in, need help
Date: Thu, 19 Aug 1999 23:18:48 +0100
I'm having a problem loggin in. After I have logged in to my localhost by
typing in root and then my password, this message appears:
[root@localhost /root#
What does this message mean and what do I type.
Help is appreciated.
Thanks
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (babu krishnamurthy)
Subject: RedHat 5.1 / 5.2 / 6.0 - development queries
Date: Tue, 17 Aug 1999 18:27:13 -0800
I am new to LINUX and currently
planning to develop Network Adapter
Device Drivers.
Could some one help me with the following queries:
1. what is the kernel version in
RedHat 5.1/5.2/6.0 ?
2. what is the extent of SMP support
in these versions ?
3. how much does it affect the Network
Adapter drivers ?
4. where can I find the details of these
Kernel internals/Network Adapter
Drivers ?
5. what are the best possible
books/resources in these areas ?
Thank you for your time.
- Babu -
-**** Posted from RemarQ, http://www.remarq.com/?b ****-
Real Discussions for Real People
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: naive newbie wants to call add_timer()
Date: Wed, 18 Aug 1999 18:12:16 GMT
On Wed, 18 Aug 1999 15:16:35 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Ok, thanks. I guess I'll go try and learn about modules.
>
>Also, is there no service available to a "hosted program" that offers
>periodic timer/callback (as opposed to sleep()) ?
You can use setitimer() to have a periodic alarm signal delivered to your
process, or use LinuxThreads to create a timer thread which performs
callouts.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
