User-friendly way to issue chown commands on remote servers

Question

I'd like my technically unversed users to have, on demand, the benefit of chown commands giving them ownership of certain files being executed on remote servers. I'd like this to be doable without administrators' involvement and with no physical access to the servers by any of the users being entailed.
By "benefit of chown commands" I mean the results a competent user would get entering the command if he or she were actually doing so. By "technically unversed" I mean specifically that said users aren't and won't ever be trained to ssh into subject servers and issue chown commands themselves directly.
I should mention that the "Get Info" interface does not in this case avail users of a way to take ownership of particular files because ACEs apply to the files in question. That ACEs apply changes what is presented: instead of any editable fields under Ownership and Permissions, all users see in the "Get Info" interface is a list of whatever ACEs apply.
Please note that users do, by virtue of ACEs, have "change ownership" permissions for the files in question. Also, authentication to the servers in question under subject users' own logins is possible as necessary.
What I'd like to start with is getting some idea how complicated this could be for me to do myself as a beginning AppleScripter. I'll describe what I guess would be involved and hope for someone to shed light.
I'm guessing that something the user at his or her own machine does involving a file he or she has selected would constitute an Apple Event which a process on the client would send to a process on the server. Then I expect the server process would issue the chown command locally respectively of
1) which file was selected when the Apple Event took place, and
2) subject user's identity.
Finally, I expect some feedback might contingently be sent to client process incidentally to need to give user feedback.
Is this a fair sketch of how this should work? What is a beginner with limited time likely to accomplish attempting this?
(Find context for this posting here: http://discussions.apple.com/thread.jspa?threadID=831517&tstart=0)
PowerMac   Mac OS X (10.4.8)  

Answer 1

First, if I understand you correctly, I'd be using
Curl and, say, Perl rather than Applescript to get
this done. In other words, what you wrote in
Applescript is about all I'd need in that
language--yes?
That's correct, give or take any errors in the script. (For obvious reasons I didn't test it.)
Then, please note that I want to chown, not chmod. Is
this an issue?
Nope. (Beyond what you pointed out below.)
I am looking at Perl documentation and read that "on
most systems, you are not allowed to change the
ownership of the file unless you're the superuser..."
(http://perldoc.perl.org/functions/chown.html).
However, isn't apache running as root?
I never thought about that. Wow, this is complicated! Are you really sure you can't make do with chmod instead?
Anyway, the answer is yes and no. The main Apache process usually runs as root, but executes CGI scripts (and other requests) as another user to avoid inherent insecurity. So unless you do something terribly, terribly insecure, you will not be able to chown from Perl. (And, although I am often lax about security, enabling root access for CGIs strikes even me as dangerous, which means it's a very bad idea.)
Really what you want is for the CGI, which does not run as root, to hand off to another process which does. I'm not a Unix guru, and would never claim to be, but I think the two following methods might work:
1. Set up a cron job running as root which looks in a directory once every minute/hour/whatever. The file name should be the user to change the owner to, and it should contain a delimited (in some form; return is possibly safe) list of files. Have the cron job walk through the list of files and use chown, then clobber the contents of the file. (Note that a CGI can use "chmod", which can make sure that the files it creates in the directory are readable by the cron job.) (Also note that you'll want to use flock to avoid race conditions between the cron job and the CGI!) This method would not be instantaneous, since the cron job only runs periodically.
2. Set up a script which runs as root which takes a line of text in the format:
user:path/to/file
and executes chown using that information. Make this process run at startup as root. Have it open a named pipe, with permissions such that CGI script can write to it, and watch for input from that pipe.
Some general notes:
A. Whatever you do, make sure that the binary/script/whatever running as root can't be written to by anyone who doesn't have root permissions.
B. Make sure to check that the user and file actually exist before doing anything with them. (And make sure to do it in the root process, since you have no guarantee that someone won't figure out what's going on and come up with some clever injection scheme to make your root process break security.) (And don't do it by passing a command to the shell; use Perl's chown or some equivalent, so that you'll be somewhat less vulnerable.)
C. For that matter, don't forget to check and make sure that the path you're about to chown is within the share point, and that the user you're going to chown to makes sense in context, so that nobody can (for example) take over someone else's user directory, or get write permission to /sbin, or something evil like that. (In fact, it might be for the best if you limited the chown operations to files only, just to be sure.)
Also, I get the part about how a constraint involving
"do shell script" method argues against using pure
Applescript in this case. But just for my information
is Applescript otherwise sufficiently capable?
If it weren't such matter of getting everything on
one line, could Applescript send commands between
hosts, convert local paths to paths on servers, issue
change ownership commands, and handle authentication?
Do methods adequate to those purposes exist in
Applescript?
Or would using multiple scripting languages be
entailed anyway? I'm guessing the latter.
Yes and no. Helpful answer, right?
First and foremost: AppleScript was originally created as a language to control programs, which would have an extensible grammar through the installation of files called "Scripting Additions". It has since been puffed up via AppleScript Studio to an application-building language in its own right, but the language itself does not have support for a lot of things which, nevertheless, the language can do by controlling another program or by extension.
AppleScript can send messages between hosts. If the remote host is a Mac, and has "Remote Apple Events" turned on in the "Sharing" control panel, then you can send commands to programs on the remote machine almost exactly as though they were local. (The only differences are in how you specify the application and how you let AppleScript know what the remote application "understands".) This support is built into the language.
If the remote host is not a Mac, you must control a program which can "translate". When it comes to terminal programs, for security reasons Apple did not include any interactive systems which could be controlled. (Although they did include "expect", I see, which would theoretically allow you to work around this...)
Since converting a path is really just text processing, yes, AppleScript can do that. I didn't try to build that in because I am under the impression that you know some other language/shell scripting tool better than AppleScript, so it makes better sense for you to put as much of the work into the parts you know, in order to make debugging easier. One method of doing it in AppleScript:
set x to [a POSIX path found somehow for a file on a connected server]
if (the offset of "/Volumes/" in x) is 1 then
-- "the offset of" uses 1-based offsets, not 0 as in most languages
set x to text 10 through -1 of x
-- This removes "/Volumes/" from the beginning of x
set x to text ((the offset of "/" in x) + 1) through -1 of x
-- That removes up through the next slash, which is the volume name
set x to "/Path/To/The/Share/Point/On/The/Server/" & x
else
error "The path isn't in /Volumes/, so either the server is mounted in a nonstandard way or the path isn't on a remote host at all." number 9000
end if
(The other method of which I am aware is to change AppleScript's text item delimiter to "/", convert the path to a list, test whether the first item is "Volumes", then put together items 3 and up into a string again. I have always had a semi-irrational prejudice against using this method because Apple's documentation circa about 1996, from which I learned AppleScript, made it sound like this might be dangerous, but it works.)
The Finder (which can be scripted) can apparently change ownership and permissions -- a fact which I did not know until just now; I must have missed it last time I looked for it -- and of course "do shell script" can be used to call "chmod" and "chown". The problem with both of these methods, vis-a-vis your particular difficulty, is that your files are not local. You could turn on Remote Apple Events and have the Finder do it, but that's really a security hole. And a potentially maddening one to figure out if anyone starts exploiting it.
I'd stick with a CGI and the cron/named pipe scheme. No matter what you do you're going to have a little extra security risk, just because chown requires root permissions, but minimizing that risk is probably a good thing.