Welcome to WebmasterWorld Guest from

Forum Moderators: bakedjake

Message Too Old, No Replies

Need to utime (or touch) from http

user nobody doesn't cut it

5:10 pm on May 22, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 10, 2001
votes: 0

I have a perl script that works just fine when I'm logged into the shell.

3 lines, just:
my @fspec = ("/pathtothefile/thefile.htm");
my $now = time;
my $rv = utime ($now, $now, @fspec);

I think there's a 'touch' function in php that does the same thing. I've researched it and 'touch' can't really be done on php by just anybody.

Obviously, when I'm logged in to the shell, and I'm the owner, this will work.

I want to be able to run it from my browser (or actually, my application - I can send headers and such simulating a browser).

One thing I haven't tried (because I don't think it will work is .htaccess authentication) - That doesn't id me as the owner does it...just as a user on the domain.

What I'm looking for is an authentication method thru http that will identify me as the shell account owner of this file. Is this possible? If not, is there a way of doing it through FTP? - any raw FTP commands...

I hope I'm clear on this. I won't be using a browser or FTP client; but I can send headers and anything else through other programming methods.

P.S. One more thing that I've considered, but I just don't know *nix well enough. If I could send the parameters (user/pass) to the script, is there a way that the script can log me on as the owner before executing the three lines above?

7:03 am on May 23, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member marcia is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Sept 29, 2000
votes: 0

Just read something today on that, bobriggs. It's shell.pl formerly known as nobody.pl, just scroll down the page a bit:


Will that do it?

2:20 pm on May 23, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 10, 2001
votes: 0

No, that's the problem. A lot of shell commands can be run without specific permissions. touch and utime require the user to be the owner of the file. That script is user nobody on Unix (apache), I scanned through it and I think it will let you log on in a Win environment. But thanks, I'm a little bit closer now.

I used the script and tried executing the login command like this:

login myusername < apassfilewithmyplaintextpassword

and I did get the shell output from that command that I see when I ssh. However, at the end of the output, there is also this:

Warning: no access to tty (Bad file descriptor). Thus no job control in this shell.

So I don't know how close I am or not.

Executing the touch command (touch [parameters] /pathtofile/filename) gives an access denied because you have to be logged in as the owner. Same thing with the utime perl builtin, except the specific error message is 'Operation not permitted'

2:39 pm on May 23, 2002 (gmt 0)

Full Member

10+ Year Member

joined:Feb 5, 2002
votes: 0

if you have user1 and user2 on one machine, can't you put user2 in the rhosts for user1 then as user2 use "remsh <host> -l user1 'touch filename'"to do a touch? or maybe you could create a script that does a setuid.

just brainstorming really!

1:48 am on May 24, 2002 (gmt 0)

Full Member

10+ Year Member

joined:Mar 14, 2002
votes: 0

Maybe I am too naive, but why not changing the owner of the files that will be touched to 'nobody' using chown?

<added> nevermind, looks like that needs privileges. </added>

8:30 am on May 24, 2002 (gmt 0)

Preferred Member

10+ Year Member

joined:Oct 4, 2000
votes: 0

Then ask your sysadmin to change these...or am I missing something fundemental here?
8:54 am on May 24, 2002 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:July 6, 2000
votes: 0

If your script runs okay when you're logged in as 'user' you could always setuid it so that it always runs with the owner's permissions rather than as user 'nobody':

chmod 4755 yourscript.pl

This should work, with a few caveats: setuid can be dangerous as it potentially gives access to your login if an attacker can find a security flaw in your script (normally, if they did hack your script they'd only have access to the 'nobody' account).

Secondly, Perl will always run in 'taint' mode when executing setuid scripts, which may mean you have to tighten up some aspects of your coding before it'll run. Try running your script using '#!/usr/bin/perl -t' to see if it complains at all.

Also, some hosts ban setuid altogether as it can cause problems in the wrong hands ;)