lkml.org 
[lkml]   [1999]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problems with NFS write of setuid executeables
Hi, Im having a similar problem with a setuid program and nfs. My client
machines are Redhat 5.2 with 2.2.1 kernels and knfs-981204. My nfs server
is also redhat-5.2 with 2.2.1 and knfsd-981204. My problem comes from my
web server. I have frontpage extensions installed on the server. Now if I
try to delete a folder trough the frontpage explorer the server replies
that it can not remove the directory. A strace of the executable shows
RESOURCE BUSY? SEE BELOW:

time(NULL) = 924231786
lstat("/webpath/virtuals/s/o/somenewdomain1.com/web/testing", {st_mode=0,
st_size=0, ...}) = 0
brk(0x82bc000) = 0x82bc000
stat("/webpath/virtuals/s/o/somenewdomain1.com/web/testing", {st_mode=0,
st_size=0, ...}) = 0
open("/webpath/virtuals/s/o/somenewdomain1.com/web/testing", O_RDONLY) = 7
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
brk(0x82bd000) = 0x82bd000
getdents(7, 0 28
12 28
/* 2 entries */, 4096) = 28
getdents(7, /* 0 entries */, 4096) = 0
close(7) = 0
stat("/webpath/virtuals/s/o/somenewdomain1.com/web/testing", {st_mode=0,
st_size=0, ...}) = 0
open("/webpath/virtuals/s/o/somenewdomain1.com/web/testing", O_RDONLY) = 7
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
getdents(7, 0 28
12 28
/* 2 entries */, 4096) = 28
getdents(7, /* 0 entries */, 4096) = 0
rmdir("/webpath/virtuals/s/o/somenewdomain1.com/web/testing") = -1 EBUSY
(Device or resource busy)
brk(0x82be000) = 0x82be000
close(7)
END STRACE:
Now the funny thing is that ..the programs work fine off of the local
filesystem. Also i have another server with the same config except that its
using kernel 2.0.36 and plain old userland nfs. This server has no problems
with the nfs deletes. The wierdest thing ..is that delete folder/dir is the
only function that doesnt work through frontpage, i can rename folders,
delete individual pages, move dirs/files to other dirs etc. I personally
think there is some hang with lockd/statd ..which i have both running on
both the client and the server. I do know that the frontpage extensions
call a setuid executable to execute the stub programs, can anyone tell me
if there is a problem with lockd ..that i should be aware of? Thanks for
the time.
jpd


At 05:04 PM 4/16/99 +0200, Max Weninger wrote:
>Hi,
>
>I discovered a problem when writing on NFS mounted directories using a
>"setuid" executeable. (Exactly it is a problem when using RCS) I am not
>sure where this problem is located.
>So any help would be nice.
>
>
>My environment:
>
>RedHat 5.2 on AlphaLinux
>2.2.5 with latest NFSv3 patch
>glibc-2.0.7
>egcs-1.1.2
>
>The following simple program test a sequence
>-fopen
>-fwrite
>-fclose
>
>On first a local and second on a NFS mounted directory.
>(The same way it is done from RCS)
>
>----------------------------------------------------
>
>#include <stdio.h>
>#include <string.h>
>#include <unistd.h>
>#include <sys/types.h>
>
>int main(int argc, char ** argv)
>{
> FILE *f;
> int res;
> char testString[1024]="just a test";
> int len;
> uid_t uid, ruid;
>
> len=strlen(testString);
> uid=getuid();
> ruid=geteuid();
> seteuid(ruid);
>
> f=fopen("/tmp/test_out.txt","w");
> if(f==0){
> printf("fopen failed\n");
> return -1;
> }
> seteuid(uid);
>
> res=fwrite(testString,1,len,f);
> if(res!=len){
> printf("fwrite failed\n");
> return -1;
> }
> fflush(f);
>
> seteuid(ruid);
>
> res=fclose(f);
> if(res!=0){
> printf("fclose failed\n");
> return -1;
> }
>
> unlink("/tmp/test_out.txt");
> seteuid(uid);
> printf("ok\n");
>
>
> seteuid(ruid);
>
f=fopen("/mnt/Projects/SNiFF+/Repository/sniffng/config/templates/RCS/test_o
ut.txt","w");
> if(f==0){
> printf("fopen failed\n");
> return -1;
> }
> seteuid(uid);
>
> res=fwrite(testString,1,len,f);
> if(res!=len){
> printf("fwrite failed\n");
> return -1;
> }
> fflush(f);
>
> seteuid(ruid);
>
> res=fclose(f);
> if(res!=0){
> printf("fclose failed\n");
> return -1;
> }
>
>
unlink("/mnt/Projects/SNiFF+/Repository/sniffng/config/templates/RCS/test_ou
t.txt");
> seteuid(uid);
> printf("ok\n");
>}
>
>---------------------------------------------------------------------------
------------------
>
>The executeable is "setuid" for the user wsadm(uid=135)
>
>-rwsr-xr-x 1 wsadm t5-dev 15915 Apr 16 16:42 test_nfs*
>
>
>It gives the following strace output when started for user e.g. max
>(uid=111)
>
>---------------------------------------------------------------------------
---------
>
>setreuid(4294967295, 135) = 0
>open("/tmp/test_out.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
>setreuid(4294967295, 111) = 0
>
>write(3, "just a test", 11) = 11
>
>setreuid(4294967295, 135) = 0
>close(3) = 0
>setreuid(4294967295, 111) = 0
>
>
>setreuid(4294967295, 135) = 0
>open("/mnt/Projects/SNiFF+/Repository/sniffng/config/templates/RCS/test_out
.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
>setreuid(4294967295, 111) = 0
>
>write(3, "just a test", 11) = 11
>
>setreuid(4294967295, 135) = 0
>
>>>>>>>>>>>>> close(3) = -1 EACCES
(Permission denied)
>
>write(1, "fclose failed\n", 14fclose failed
>) = 14
>
>exit(-1) = ?
>
>-------------------------------------------------------------------
>
>The second close(3) failed on the NFS directory
>
>The mount options are:
>lucky:/export4 on /mnt type nfs (rw,addr=193.81.18.250)
>
>The intresting is that when i remove the fflush(f) before the fclose
>it works
>
>......
>setreuid(4294967295, 135) = 0
>open("/mnt/Projects/SNiFF+/Repository/sniffng/config/templates/RCS/test_out
.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
>setreuid(4294967295, 111) = 0
>
>setreuid(4294967295, 135) = 0
>write(3, "just a test", 11) = 11
>close(3) = 0
>.....
>
>Then the write call comes AFTER the setreuid call
>
>
>Regards
>
>Max
>
>--
>_______________________________________________________________
> \
> o/\_ DI Max Weninger
> <\__,\ Email (max@takefive.co.at)
> ">. |
> ` .-| TakeFive Software - Jakob-Haringer-Str. 8
> . \ A-5020 Salzburg - AUSTRIA
> . \ Tel: +43 662 4579150 - Fax: +43 662 4579156
> .-|
>_________._|____________________________________________________
>
>
>-
>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/
>

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.603 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site