Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: bakedjake
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?
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'
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 ;)