[parisc-linux] Issues with seteuid()?

[parisc-linux] Issues with seteuid()?

[Luigi Gangitano]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]


Hi all,
I'm the Debian package maintainer for Squid (HTTP Proxy). I received the
forwarded bug report describing issues in seteuid() on palinux. While
using seteuid(), forked processes terminate with SEGV.

Is it a known problem?

Thanks.

L

Please CC: me, I'm not subscribed to this list.

-----Forwarded Message-----
> This small mail to mentionned that I reach to make squid operational on
> a linux-2.4.20-pa17 thanks to the following tips:
> 
> in debian rules replace statement
>     ac_cv_func_setresuid=no \
> by
>     ac_cv_func_setresuid=yes \
> 
> so that function leave_suid() [into src/tools.c] will use setresuid() in
> place of seteuid() before launch fork().
> 
> Is it a know problem on palinux?
> 
> Greetings,
>     Joel
> 
> PS: Luigi, I also test it on 2.5.1 and it works also for parisc linux (testing
> config). HTH

-- 
 Luigi Gangitano -- <luigi@debian.org> -- <gangitano@lugroma3.org>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [parisc-linux] Issues with seteuid()?

[Matthew Wilcox]

On Sun, Jan 12, 2003 at 04:49:29PM +0100, Luigi Gangitano wrote:
> I'm the Debian package maintainer for Squid (HTTP Proxy). I received the
> forwarded bug report describing issues in seteuid() on palinux. While
> using seteuid(), forked processes terminate with SEGV.
> 
> Is it a known problem?

I wonder how it can be a problem at all.  The kernel implements only
sys_setresuid() and i would imagine that glibc implements both
seteuid() and setresuid() in terms of this system call.

Perhaps someone who's willing to touch glibc would care to comment?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Issues with seteuid()?

[Randolph Chung]

> I wonder how it can be a problem at all.  The kernel implements only
> sys_setresuid() and i would imagine that glibc implements both
> seteuid() and setresuid() in terms of this system call.
> 
> Perhaps someone who's willing to touch glibc would care to comment?

seteuid() works fine in simple tests. i don't think it's seteuid...
something else is broken. can someone provide a simple test case for the
segfault?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Issues with seteuid()?

[jsoe0708]

Hi Randolph,

Being the author of bug report (and some other request on this ml about
subject), unfortunately I do not have test case. But what I can do is to
explain all what I did. I just grab squid-2.4.7-1 (hope still exist) and
rebuild as it is (check in rules that ac_cv_func_setresuid=3Dno).

Installed it and disabled the startup script (in case of reboot, it risks=

to make boot very slow).

I already noticed that the install procedure failled to create the spool
dir; dmesg would have to confirm you that squid do a segv. [ and there wa=
s
no squid process ]

What failled? In fact, the install script launched 'squid -z'.
It was interesting to launch it manually; the reason of the SEGV was more=

complete: fork failled because not enough memory available??

Well fork() failed... Searching in sources (MANY THANKS to RMS for FSF sp=
irit)
I find the place where fork() is used and what happened just before: acco=
rding
to configure param, it do first a setgroups(), setgid() then (in this cas=
e)
a seteuid() (function leave_suid() in src/tools.c).

So the problem seems to came from a kind of su. And I re-read Bach UNIX
bible to remember that one of the first think that do a su is to verify
that user memory is enough. In this case it considered that it was not th=
e
case?

So I tried to check if a real su presents the same problem. I let first
read access to the world for /etc/squid.conf (just for the test) and as
in the startup script 'ulimit -n 5120' (for example) then 'su - proxy'.

'ulimit -a' seems Ok.
Now, always as proxy user, relaunch 'squid -z' and ... it works.

I could be now quiet sure that the problem came from the setgroups(), set=
gid(),
seteuid(), fork() sequence used to switch user. Agree?

I first checked the value of the paramters transmitted to the seteuid()
which seem ok.

As I saw that the developper of squid foreseen other procedure to su, I
did so first investigate to use setreuid() (which seems to me also more
secure but I should be wrong?). As it was available, I test it and solved=

all the squid problem encounter since the begining: the creation of the
spool dir was now ok and the server worked fine. That is this final concl=
usion
that I transmitted as bug report near squid maintainer.

On this mailing list my question (<http://lists.parisc-linux.org/pipermai=
l/parisc-linux/2003-January/018801.html>)
was a bit wilder (I thought but wrongly):
is it a seteuid() [glic ?] or a fork() [kernel ?] problem?

Well that is only a summary a many other investigation and I hope this he=
lp
but if something is not clear or some other test would help you do not he=
sitate
to let me know,

Cheers,
    Joel


->> I wonder how it can be a problem at all.  The kernel ilements only
>> sys_setresuid() and i would imagine that glibc implements both
>> seteuid() and setresuid() in terms of this system call.
>>
>> Perhaps someone who's willing to touch glibc would care to comment?
>
>seteuid() works fine in simple tests. i don't think it's seteuid...
>something else is broken. can someone provide a simple test case for the=

>segfault?
>
>randolph
>--
>Randolph Chung
>Debian GNU/Linux Developer, hppa/ia64 ports
>http://www.tausq.org/
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux



*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

RE: [parisc-linux] Issues with seteuid()?

[Joel Soete]

Hi all,

Here is a 'small' test case which reproduce the problem on a sarge (ie testing)
debian (gcc-3.0_3.0.4-12; libc6_2.2.5-14.3) running very last kernel 2.4.20-pa23:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

/* getpid(), geteuid()  */
#include <sys/types.h>
#include <unistd.h>

/* setgroups() */
#include <grp.h>

/* mkdir() */
#include <sys/stat.h>
#define MAXPATHLEN 256

/* waitpid() */
#include <sys/wait.h>


char *effectiveUser="proxy";
uid_t effectiveUserID=13;
gid_t effectiveGroupID=13;

/* Define if you have the setgroups function.  */
#define HAVE_SETGROUPS 1

/*
 * Yay! Another Linux brokenness.  Its not good enough to know that
 * setresuid() exists, because RedHat 5.0 declare setresuid() but
 * doesn't implement it.
 */
#define HAVE_SETRESUID 1

#undef HAVE_SETRESUID
/*
 */

/*
man setresuid NOTES:
       Under  HP-UX  and  FreeBSD the prototype is found in <unistd.h>. 
Under
       Linux there is so far no include file giving the prototype - this
is  a
       glibc bug. Programs using this system call must add the prototype
them-
       selves.
*/
#ifdef HAVE_SETRESUID
int
setresuid(uid_t ruid, uid_t euid, uid_t suid);
#endif

/* Define if you have the seteuid function.  */
#define HAVE_SETEUID 1

/*
 * xstrerror() - strerror() wrapper
 */
const char *
xstrerror(void)
{
    static char xstrerror_buf[BUFSIZ];
    static char strerror_buf[BUFSIZ];

    snprintf(strerror_buf, BUFSIZ, "%s", strerror(errno));
   
    if (strerror_buf) 
	snprintf(xstrerror_buf, BUFSIZ, "(%d) %s", errno, strerror_buf);
    else
        snprintf(xstrerror_buf, BUFSIZ, "(%d) Unknown", errno); 
    return xstrerror_buf;
}

/* leave a privilegied section. (Give up any privilegies)
 * Routines that need privilegies can rap themselves in enter_suid()
 * and leave_suid()
 * To give upp all posibilites to gain privilegies use no_suid()
 */
void
leave_suid(void)
{
    fprintf(stderr, "leave_suid: PID %d called\n", (int) getpid());
    if (geteuid() != 0)
	return;
    /* Started as a root, check suid option */
    if (effectiveUser == NULL)
	return;
#if HAVE_SETGROUPS
    setgroups(1, &effectiveGroupID);
#endif
    if (setgid(effectiveGroupID) < 0)
	fprintf(stderr, "ALERT: setgid: %s\n", xstrerror());
    fprintf(stderr, "leave_suid: PID %d giving up root, becoming '%s'\n",
(int) getpid(), effectiveUser);
#if HAVE_SETRESUID
    if (setresuid(effectiveUserID, effectiveUserID, 0) < 0)
	fprintf(stderr, "ALERT: setresuid: %s\n", xstrerror());
#elif HAVE_SETEUID
    if (seteuid(effectiveUserID) < 0)
	fprintf(stderr, "ALERT: seteuid: %s\n", xstrerror());
#else
    if (setuid(effectiveUserID) < 0)
	fprintf(stderr, "ALERT: setuid: %s\n", xstrerror());
#endif
}

static void
setEffectiveUser(void)
{
    leave_suid();		/* Run as non privilegied user */
    if (geteuid() == 0) {
	fprintf(stderr, "Squid is not safe to run as root!  If you must\n");
	fprintf(stderr, "start Squid as root, then you must configure\n");
	fprintf(stderr, "it to run as a non-priveledged user with the\n");
	fprintf(stderr, "'cache_effective_user' option in the config file.\n");
	fprintf(stderr, "Don't run Squid as root, set 'cache_effective_user'!\n");
        abort();
    }
}

static int
storeUfsDirCreateDirectory(const char *path)
{
    int created = 0;

    if (0 != mkdir(path, 0755)) {
	fprintf(stderr,	"Failed to make swai directory %s: %s\n",
	    path, xstrerror());
    }
    return created;
}

static void
storeUfsDirCreateSwapSubDirs(char * Path)
{
    int i, k;
    static char name[MAXPATHLEN];
    for (i = 0; i < 16; i++) {
	snprintf(name, MAXPATHLEN, "%s/%02X", Path, i);
        storeUfsDirCreateDirectory(name);
	fprintf(stderr, "Making directories in %s\n", name);
	for (k = 0; k < 32; k++) {
	    snprintf(name, MAXPATHLEN, "%s/%02X/%02X", Path, i, k);
            storeUfsDirCreateDirectory(name);
	}
    }
}


static void
storeUfsDirNewfs(char * Path)
{
    fprintf(stderr, "Creating swap space in %s\n", Path);
    storeUfsDirCreateSwapSubDirs(Path);
}

void
storeCreateSwapDirectories(void)
{
    int i;
    pid_t pid;
    int status;
    for (i = 0; i < 1; i++) {
	if (fork())
	    continue;
        storeUfsDirNewfs("/var/spool/squid");
	exit(0);
    }
    do {
	pid = waitpid(-1, &status, 0);
    } while (pid > 0 || (pid < 0 && errno == EINTR));
}


int
main(int argc, char **argv)
{
    /* only opt_create_swap_dirs */

    setEffectiveUser();
    fprintf(stderr, "Creating Swap Directories\n");
    storeCreateSwapDirectories();

    return 0;
}

(rebuild from simplified parts of squid-2.5 src)

compile with: gcc -O 2 -Wall -D_REENTRANT file.c -o ct

[create a user and a group named proxy with id 13 both]

compile as it is it, it will failled immediately with 'Segmentation fault'

edit sources to comment out '#undef HAVE_SETRESUID' line, recompile with
same option and it would fork without problem (even thought it will failled
to actually create dir)

hth,
    Joel

PS: this test case doesn't present the same pb on an unstable debian (ie
compile with gcc-3.2_3.2.2-0pre6 & libc6_2.3.1-10). I try this on the same
kernel running each the two different install.



>-- Original Message --
>From: Luigi Gangitano <luigi@debian.org>
>To: parisc-linux@lists.parisc-linux.org
>Subject: [parisc-linux] Issues with seteuid()?
>Date: 12 Jan 2003 16:49:29 +0100
>
>
>
>Hi all,
>I'm the Debian package maintainer for Squid (HTTP Proxy). I received the
>forwarded bug report describing issues in seteuid() on palinux. While
>using seteuid(), forked processes terminate with SEGV.
>
>Is it a known problem?
>
>Thanks.
>
>L
>
>Please CC: me, I'm not subscribed to this list.
>
>-----Forwarded Message-----
>> This small mail to mentionned that I reach to make squid operational on
>> a linux-2.4.20-pa17 thanks to the following tips:
>> 
>> in debian rules replace statement
>>     ac_cv_func_setresuid=no \
>> by
>>     ac_cv_func_setresuid=yes \
>> 
>> so that function leave_suid() [into src/tools.c] will use setresuid()
in
>> place of seteuid() before launch fork().
>> 
>> Is it a know problem on palinux?
>> 
>> Greetings,
>>     Joel
>> 
>> PS: Luigi, I also test it on 2.5.1 and it works also for parisc linux
(testing
>> config). HTH
>
>-- 
> Luigi Gangitano -- <luigi@debian.org> -- <gangitano@lugroma3.org>
> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26
>
>Attachment: signature.asc
>


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] Issues with seteuid()?

[Joel Soete]

Hi Randolph,

As per your request, I do spent some time to compose this 'small' test case
bases on simplified parts of squid:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

/* getpid(), geteuid()  */
#include <sys/types.h>
#include <unistd.h>

/* setgroups() */
#include <grp.h>

/* mkdir() */
#include <sys/stat.h>
#define MAXPATHLEN 256

/* waitpid() */
#include <sys/wait.h>


char *effectiveUser="proxy";
uid_t effectiveUserID=13;
gid_t effectiveGroupID=13;

/* Define if you have the setgroups function.  */
#define HAVE_SETGROUPS 1

/*
 * Yay! Another Linux brokenness.  Its not good enough to know that
 * setresuid() exists, because RedHat 5.0 declare setresuid() but
 * doesn't implement it.
 */
#define HAVE_SETRESUID 1

#undef HAVE_SETRESUID
/*
 */

/*
man setresuid NOTES:
       Under  HP-UX  and  FreeBSD the prototype is found in <unistd.h>. 
Under
       Linux there is so far no include file giving the prototype - this
is  a
       glibc bug. Programs using this system call must add the prototype
them-
       selves.
*/
#ifdef HAVE_SETRESUID
/* because man setresuid mentionned it as a lake of linux? */
int
setresuid(uid_t ruid, uid_t euid, uid_t suid);
#endif

/* Define if you have the seteuid function.  */
#define HAVE_SETEUID 1

/*
 * xstrerror() - strerror() wrapper
 */
const char *
xstrerror(void)
{
    static char xstrerror_buf[BUFSIZ];
    static char strerror_buf[BUFSIZ];

    snprintf(strerror_buf, BUFSIZ, "%s", strerror(errno));
   
    if (strerror_buf) 
	snprintf(xstrerror_buf, BUFSIZ, "(%d) %s", errno, strerror_buf);
    else
        snprintf(xstrerror_buf, BUFSIZ, "(%d) Unknown", errno); 
    return xstrerror_buf;
}

/* leave a privilegied section. (Give up any privilegies)
 * Routines that need privilegies can rap themselves in enter_suid()
 * and leave_suid()
 * To give upp all posibilites to gain privilegies use no_suid()
 */
void
leave_suid(void)
{
    fprintf(stderr, "leave_suid: PID %d called\n", (int) getpid());
    if (geteuid() != 0)
	return;
    /* Started as a root, check suid option */
    if (effectiveUser == NULL)
	return;
#if HAVE_SETGROUPS
    setgroups(1, &effectiveGroupID);
#endif
    if (setgid(effectiveGroupID) < 0)
	fprintf(stderr, "ALERT: setgid: %s\n", xstrerror());
    fprintf(stderr, "leave_suid: PID %d giving up root, becoming '%s'\n",
(int) getpid(), effectiveUser);
#if HAVE_SETRESUID
    if (setresuid(effectiveUserID, effectiveUserID, 0) < 0)
	fprintf(stderr, "ALERT: setresuid: %s\n", xstrerror());
#elif HAVE_SETEUID
    if (seteuid(effectiveUserID) < 0)
	fprintf(stderr, "ALERT: seteuid: %s\n", xstrerror());
#else
    if (setuid(effectiveUserID) < 0)
	fprintf(stderr, "ALERT: setuid: %s\n", xstrerror());
#endif
}

static void
setEffectiveUser(void)
{
    leave_suid();		/* Run as non privilegied user */
    if (geteuid() == 0) {
	fprintf(stderr, "Squid is not safe to run as root!  If you must\n");
	fprintf(stderr, "start Squid as root, then you must configure\n");
	fprintf(stderr, "it to run as a non-priveledged user with the\n");
	fprintf(stderr, "'cache_effective_user' option in the config file.\n");
	fprintf(stderr, "Don't run Squid as root, set 'cache_effective_user'!\n");
        abort();
    }
}

static int
storeUfsDirCreateDirectory(const char *path)
{
    int created = 0;

    if (0 != mkdir(path, 0755)) {
	fprintf(stderr,	"Failed to make swai directory %s: %s\n",
	    path, xstrerror());
    }
    return created;
}

static void
storeUfsDirCreateSwapSubDirs(char * Path)
{
    int i, k;
    static char name[MAXPATHLEN];
    for (i = 0; i < 16; i++) {
	snprintf(name, MAXPATHLEN, "%s/%02X", Path, i);
        storeUfsDirCreateDirectory(name);
	fprintf(stderr, "Making directories in %s\n", name);
	for (k = 0; k < 32; k++) {
	    snprintf(name, MAXPATHLEN, "%s/%02X/%02X", Path, i, k);
            storeUfsDirCreateDirectory(name);
	}
    }
}


static void
storeUfsDirNewfs(char * Path)
{
    fprintf(stderr, "Creating swap space in %s\n", Path);
    storeUfsDirCreateSwapSubDirs(Path);
}

void
storeCreateSwapDirectories(void)
{
    int i;
    pid_t pid;
    int status;
    for (i = 0; i < 1; i++) {
	if (fork())
	    continue;
        storeUfsDirNewfs("/var/spool/squid");
	exit(0);
    }
    do {
	pid = waitpid(-1, &status, 0);
    } while (pid > 0 || (pid < 0 && errno == EINTR));
}


int
main(int argc, char **argv)
{
    /* only opt_create_swap_dirs */

    setEffectiveUser();
    fprintf(stderr, "Creating Swap Directories\n");
    storeCreateSwapDirectories();

    return 0;
}

A. On a testing debian system (ie gcc-3.0 3.0.4-10 && libc6 2.2.5-14.3) and
the very last kernel 2.4.20-pa23:

Compile with gcc -O 2 -Wall -D_REENTRANT foo.c -o foo

[ Create a user and a group named proxy with id 13 for both ]

First as it is ./foo would failled to fork() immediately with 'Segmentation
fault'.

Secondly edit foo.c to comment out #undifined HAVE_SETRESUID; it would reach
to fork without problem (eventhough it did not reach to create dir)

B. On an unstable debian (ie gcc-3.2 3.2.2-0pre6 && libc6 2.3.1-10) running
the same kernel: this problem doesn't occure.

hth,
    Joel


>-- Original Message --
>From: Randolph Chung <tausq@debian.org>
>To: Matthew Wilcox <willy@debian.org>
>Cc: Luigi Gangitano <luigi@debian.org>,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Issues with seteuid()?
>Reply-To: Randolph Chung <tausq@debian.org>
>Date: Sun, 12 Jan 2003 19:11:09 -0800
>
>
>> I wonder how it can be a problem at all.  The kernel implements only
>> sys_setresuid() and i would imagine that glibc implements both
>> seteuid() and setresuid() in terms of this system call.
>> 
>> Perhaps someone who's willing to touch glibc would care to comment?
>
>seteuid() works fine in simple tests. i don't think it's seteuid...
>something else is broken. can someone provide a simple test case for the
>segfault?
>
>randolph
>-- 
>Randolph Chung
>Debian GNU/Linux Developer, hppa/ia64 ports
>http://www.tausq.org/
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] Issues with seteuid()?

[Randolph Chung]

> A. On a testing debian system (ie gcc-3.0 3.0.4-10 && libc6 2.2.5-14.3) and
> the very last kernel 2.4.20-pa23:
> 
> Compile with gcc -O 2 -Wall -D_REENTRANT foo.c -o foo
> 
> [ Create a user and a group named proxy with id 13 for both ]
> 
> First as it is ./foo would failled to fork() immediately with 'Segmentation
> fault'.

# uname -a
Linux legolas 2.4.20-pa23 #110 Mon Jan 27 23:44:18 PST 2003 parisc unknown unknown GNU/Linux

ii  gcc-3.0        3.0.4-7        The GNU C compiler.
ii  libc6          2.2.5-14.3     GNU C Library: Shared libraries and Timezone

# gcc-3.0 -O2 -Wall -D_REENTRANT seteuid.c -o seteuid
# ./seteuid
leave_suid: PID 18443 called
leave_suid: PID 18443 giving up root, becoming 'proxy'
Creating Swap Directories
[....]

no segfault... 

can you maybe run it with strace and send the last few lines of output?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Issues with seteuid()?

[Joel Soete]

Randolph,

>
>
>> A. On a testing debian system (ie gcc-3.0 3.0.4-10 && libc6 2.2.5-14.3)
>and
>> the very last kernel 2.4.20-pa23:
>> 
>> Compile with gcc -O 2 -Wall -D_REENTRANT foo.c -o foo
>> 
>> [ Create a user and a group named proxy with id 13 for both ]
>> 
>> First as it is ./foo would failled to fork() immediately with 'Segmentation
>> fault'.
>
># uname -a
>Linux legolas 2.4.20-pa23 #110 Mon Jan 27 23:44:18 PST 2003 parisc unknown
>unknown GNU/Linux
>
>ii  gcc-3.0        3.0.4-7        The GNU C compiler.
>ii  libc6          2.2.5-14.3     GNU C Library: Shared libraries and Timezone
>
># gcc-3.0 -O2 -Wall -D_REENTRANT seteuid.c -o seteuid
># ./seteuid
>leave_suid: PID 18443 called
>leave_suid: PID 18443 giving up root, becoming 'proxy'
>Creating Swap Directories
>[....]
>
>no segfault... 
>
>can you maybe run it with strace and send the last few lines of output?
>
Well so short that I can give you all:

ii  gcc-3.0        3.0.4-10       The GNU C compiler.
ii  gcc-3.0-base   3.0.4-10       The GNU Compiler Collection (base package).
ii  libc6          2.2.5-14.3     GNU C Library: Shared libraries and Timezone


# strace -f ./a.out
execve("./a.out", ["./a.out"], [/* 18 vars */]) = 0
newuname({sys="Linux", node="fw01.office.palinux", ...}) = 0
brk(0)                                  = 0x26000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 16726, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2\37"..., 1024)
= 1024
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 1392404, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
mprotect(0x4015f000, 118548, PROT_NONE) = 0
mmap(0x4016e000, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x136000) = 0x4016e000
mmap(0x40179000, 12052, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x40179000
close(3)                                = 0
munmap(0x40018000, 16726)               = 0
getpid()                                = 25520
write(2, "leave_suid: PID 25520 called\n", 29leave_suid: PID 25520 called
) = 29
geteuid()                               = 0
setgroups(1, [13])                      = 0
setgid(13)                              = 0
getpid()                                = 25520
write(2, "leave_suid: PID 25520 giving up "..., 55leave_suid: PID 25520 giving
up root, becoming 'proxy'
) = 55
setresuid(ruid 4294967295, euid 13, suid 4294967295) = 0
geteuid()                               = 13
write(2, "Creating Swap Directories\n", 26Creating Swap Directories
) = 26
fork()                                  = -1 EAGAIN (Resource temporarily
unavailable)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


Well as explained in a previous mail if I do a su - proxy and launch same
program no problem to fork() ??

Thanks for your attention,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] Issues with seteuid()?

[Randolph Chung]

[oops, forgot to send the last message to the list -- i had asked Joel
for his ulimit settings]

> Nothing that is not std (AFAIK & IIRC):
> 
> # ulimit -a
> core file size        (blocks, -c) 0
> data seg size         (kbytes, -d) unlimited
> file size             (blocks, -f) unlimited
> max locked memory     (kbytes, -l) unlimited
> max memory size       (kbytes, -m) 5000
> open files                    (-n) 1024
> pipe size          (512 bytes, -p) 8
> stack size            (kbytes, -s) 8192
> cpu time             (seconds, -t) unlimited
> max user processes            (-u) 20
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> virtual memory        (kbytes, -v) unlimited

That's the reason..... if you do 'ulimit -u unlimited' (or at least a
bigger number) you should be ok.

randolph

Re: [parisc-linux] Issues with seteuid()?

[Joel Soete]

Randolph,

...
>> cpu time             (seconds, -t) unlimited
>> max user processes            (-u) 20
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> virtual memory        (kbytes, -v) unlimited
>
>That's the reason..... if you do 'ulimit -u unlimited' (or at least a
>bigger number) you should be ok.
>
ulimit -u unlimited 

(just for fun I can download to 64 for this test case; is there any means
to determine a reasonnable value (unstable seems to set it to 999)?)

Thanks again for all,
    Joel

PS: Where is defined this default?

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] Issues with seteuid()?

[Joel Soete]

PA,
>...
>>> cpu time             (seconds, -t) unlimited
>>> max user processes            (-u) 20
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> virtual memory        (kbytes, -v) unlimited
>>
>>That's the reason..... if you do 'ulimit -u unlimited' (or at least a
>>bigger number) you should be ok.
>>
>ulimit -u unlimited 
>
>(just for fun I can download to 64 for this test case; is there any means
>to determine a reasonnable value (unstable seems to set it to 999)?)
>
>
>PS: Where is defined this default?
>
It seems to be my bad ;_().
It appears in my own apt-get update Log that I use the default (ie N) when
the update procedure of 'libpam-modules' dpkg proposed me to change '/etc/security/limits.conf.

Sorry and thanks again for your support,

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be