C Brain Teaser - Page 2 - High Level Programming

kahuna · #8 05-10-2007

Code:

    return (unlink (argv[0]));

Would turning off permissions instead of unlinking work on HP-UX?

Code:

   return (chmod (argv[0],0));

Perderabo · #9 05-10-2007

Quote:

Originally Posted by kahuna

Would turning off permissions instead of unlinking work on HP-UX?

That operation would be legal. It's not clear that this would be enough to satify the condition of the challenge. A chmod command would reverse that. The challenge seems to imply a more complete form of self-destruction such that a second compile of the source code would be in order.

Perderabo · #10 05-10-2007

OK, here is my version. It assumes that rm is /usr/bin/rm. If your rm is elsewhere you will need a little change.

Code:

#include <stdio.h>
#include <unistd.h>
main(int argc, char *argv[])
{
        printf("Hello, world... for now!\n");
        execl("/usr/bin/rm", "rm", argv[0], 0);
}

blowtorch · #11 05-10-2007

Well, this would work. Your binary file becomes non-ETXTBSY the moment the execl is run. So no problem removing it.

matrixmadhan · #12 05-10-2007

How about this approach,

After printing the statement,
copying /dev/null to the binary
or
making the binary 0 bytes.

Binary would be still available but unable to use for the second time

I believe this would work for the challenge posted!

blowtorch · #13 05-10-2007

This is another way of going about it:

Code:

#include<stdio.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
main(int argc, char *argv[]) {
        int fd;
        char buf[]="0000000000";
        fprintf(stdout,"Hello, world... for now!\n");
        fd=open(argv[0],O_WRONLY);
        if(fd==-1) {
                perror("Could not open file");
        }
        if((write(fd,buf,strlen(buf)))==-1) {
                perror("Could not write to file");
        }
        close(fd);
}

You can run this only once. Tested on Solaris 10. Dunno about HP-UX. Am trying to get a system so that I can test this.

-Edit:
You won't know what has happened either. The file is still there, still the same size too, but it won't run anymore.

matrixmadhan · #14 05-10-2007

This is something interesting.

I wonder how it worked on solaris.

It didnt when I tried on FC3 ( as expected )

It is not possible to write an exe file when it is in use or busy. Same thing happens when a program which is running for hours together when updated with a new copy of the binary; the operation will is not permitted. Would say the text file is currently busy.

This is the error when ran in FC3

Code:

Could not open file: Text file busy
Could not write to file: Bad file descriptor

I could find that after perror the operation still continues to write to the file without a valid file descriptor which is not the proper way.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread	Thread Starter	Forum	Replies	Last Post
Wrapping Your Brain Around Oracle + Python	iBot	Oracle Updates (RSS)	0	04-06-2008 02:10 AM

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode