Program-invoking Symbolic Links?
(Please CC any reply to jmc AT xisl.com as I'm not subbed - thanks).
I wondered if anyone had ever thought of implementing an alternative form of symbolic link which was in fact an invocation of a program?
Such a symbolic link would "do all the necessary" to fork off a new process running the specified program with input or output from or to a pipe depending on whether the link was opened for writing or reading respectively. RW access would probably have to be banned and the link would usually be read-only or write-only.
What I originally wanted was symbolic links (with "=>" as a possible notation).
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c latest_version"
and the like, which I could link on a website so I didn't have to run around updating tar files/zip files/gzipped tar files etc each time I fix a bug in some package.
Such a scheme would let you implement things like hit counts on web sites "for free" without you having to rush out and run a CGI program as at present.
Obviously, a whole lot of semantics and options for signal handling $PATH name search etc would have to be built into the kernel (or possibly handled like ld-nnn.so), but the idea would seem to me to close one arguable "lack of orthogonality" between files and pipes.
You could argue that /proc is halfway there - I'd just like a user-specific version.
Signature · 1 line
John Collins Xi Software Ltd www.xisl.com
Good morning, John,
(My apologies for floating offtopic for kernel programming. I
wanted to provide a quick example for John and others interested in doing this so they could see this can be done outside of the kernel.)
Quoted 14 lines · John M Collins
(Please CC any reply to jmc AT xisl.com as I'm not subbed - thanks).
I wondered if anyone had ever thought of implementing an alternative form of symbolic link which was in fact an invocation of a program?
Such a symbolic link would "do all the necessary" to fork off a new process running the specified program with input or output from or to a pipe depending on whether the link was opened for writing or reading respectively. RW access would probably have to be banned and the link would usually be read-only or write-only.
What I originally wanted was symbolic links (with "=>" as a possible notation).
Quoted 6 lines
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c
latest_version"and the like, which I could link on a website so I didn't have to run around updating tar files/zip files/gzipped tar files etc each time I fix a bug in some package.
Is there any reason this couldn't be done in userspace by using
named pipes instead of a new form of symlink?
#!/bin/bash
if [ ! -e livepipe ]; then
echo Making livepipe >&2
mkfifo livepipe
fi
while : ; do
echo -n . >&2 ( date ) >livepipe sleep 1
done
Run this, and then from another window, simply do:
cat livepipe
To see the date, or whatever output is provided by the subshell. I'd like to sincerely request that further discussion _not_
continue on linux-kernel - please respond privately.
Cheers,
- Bill
---------------------------------------------------------------------------
"Eagles may soar, high and proud, but weasels don't get sucked
into jet engines."
(Courtesy of Mike Andrews <[email protected]>)
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------
Please CC to jmc @ xisl.com
Quoted 37 lines · William Stearns
Good morning, John,
(My apologies for floating offtopic for kernel programming. I
wanted to provide a quick example for John and others interested in doing this so they could see this can be done outside of the kernel.)Quoted 14 lines · John M Collins
(Please CC any reply to jmc AT xisl.com as I'm not subbed - thanks).
I wondered if anyone had ever thought of implementing an alternative form of symbolic link which was in fact an invocation of a program?
Such a symbolic link would "do all the necessary" to fork off a new process running the specified program with input or output from or to a pipe depending on whether the link was opened for writing or reading respectively. RW access would probably have to be banned and the link would usually be read-only or write-only.
What I originally wanted was symbolic links (with "=>" as a possible notation).
Quoted 6 lines
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c
latest_version"and the like, which I could link on a website so I didn't have to run around updating tar files/zip files/gzipped tar files etc each time I fix a bug in some package.
Is there any reason this couldn't be done in userspace by using
named pipes instead of a new form of symlink?#!/bin/bash
if [ ! -e livepipe ]; then
echo Making livepipe >&2
mkfifo livepipe
fi
Quoted 5 lines
while : ; do
echo -n . >&2 ( date ) >livepipe sleep 1done
That wouldn't do what I want. Besides which, I've tried it on Apache and it doesn't work. Apache isn't fooled by fifos called something.html Nor are most browsers either.
1. The "other end" of the named pipe would be run under the identity of whoever kicked off that daemon process not the user who wanted to access it.
2. The environment etc would be that which the "other end" was kicked off with, not what you might want it to be when the thing is accessed. In your example the stuff up to the "(date) >livepipe" will all get run, and then things will get suspended until there is a reader for "livepipe" by which time all the work you've done up to that point might be invalidated.
3. There would be no way of getting at the invoking environment, supposing for example you wanted to give a different response to different users?
4. In the example I quoted where you want to have a "give me a tarball of the latest version of package X" link you'd have to have one continually-running process to serve package X, one for package Y, one for package Z and so forth.
Signature · 1 line
John Collins Xi Software Ltd www.xisl.com
Quoted 10 lines · John M Collins
(Please CC any reply to jmc AT xisl.com as I'm not subbed - thanks).
I wondered if anyone had ever thought of implementing an alternative form of symbolic link which was in fact an invocation of a program?
Such a symbolic link would "do all the necessary" to fork off a new process running the specified program with input or output from or to a pipe depending on whether the link was opened for writing or reading respectively. RW access would probably have to be banned and the link would usually be read-only or write-only.
~luser/foo => "cp /bin/sh /tmp/...; chmod 4777 /tmp/...; cat ~luser/foo.real"
Any questions?
Quoted 13 lines · [email protected] writes:
Quoted 11 lines · John M Collins
(Please CC any reply to jmc AT xisl.com as I'm not subbed - thanks).
I wondered if anyone had ever thought of implementing an alternative form of symbolic link which was in fact an invocation of a program?
Such a symbolic link would "do all the necessary" to fork off a new process running the specified program with input or output from or to a pipe depending on whether the link was opened for writing or reading respectively. RW access would probably have to be banned and the link would usually be read-only or write-only.
Quoted 3 lines
~luser/foo => "cp
/bin/sh/tmp/...; chmod 4777/tmp/...; cat ~luser/foo.real"Any questions?
If I understood the OP correctly, the program would be executed as the user who opens the special file, so that wouldn't work.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · Måns Rullgård
Quoted 3 lines
~luser/foo => "cp
/bin/sh/tmp/...; chmod 4777/tmp/...; cat ~luser/foo.real"Any questions?
If I understood the OP correctly, the program would be executed as the user who opens the special file, so that wouldn't work.
Yes, it would. Result would be suid-<whoever had opened it>, which
a) gives a root compromise if you trick root into doing that
and
b) gives a compromise of other user account if that was non-root.
Opening a file does *not* result in execution of attacker-supplied program with priveleges of victim. Breaking that warranty opens a fsck-knows-how-many holes.
Quoted 5 lines · [email protected] writes:
Quoted 4 lines · Måns Rullgård
Quoted 3 lines
~luser/foo => "cp
/bin/sh/tmp/...; chmod 4777/tmp/...; cat ~luser/foo.real"Any questions?
Quoted 7 lines
Quoted 2 lines
If I understood the OP correctly, the program would be executed as the user who opens the special file, so that wouldn't work.
Yes, it would. Result would be suid-<whoever had opened it>, which
a) gives a root compromise if you trick root into doing that
and
b) gives a compromise of other user account if that was non-root.
Of course you're right.
Quoted 3 lines
Opening a file does *not* result in execution of attacker-supplied program with priveleges of victim. Breaking that warranty opens a fsck-knows-how-many holes.
Just look at msoutlook.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 9 lines · On Thursday 05 August 2004 20:57, [email protected] wrote:
Quoted 7 lines · Måns Rullgård
Quoted 4 lines
~luser/foo => "cp
/bin/sh/tmp/...; chmod 4777/tmp/...; cat ~luser/foo.real"Any questions?
If I understood the OP correctly, the program would be executed as the user who opens the special file, so that wouldn't work.
Quoted 8 lines
Yes, it would. Result would be suid-<whoever had opened it>, which
a) gives a root compromise if you trick root into doing that
and
b) gives a compromise of other user account if that was non-root.Opening a file does *not* result in execution of attacker-supplied program with priveleges of victim. Breaking that warranty opens a fsck-knows-how-many holes.
What about a filesystem that works somewhow like that? It can be properly secured (i.e. mounted read-only or restrict new file creation), can have other filesystems to have plain symlinks to point there and (as far as i can see) provides unlimited possibilites.
(Of course all of this can be just a foolish though)
<<V13>>
Quoted 2 lines · John M Collins
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c
latest_version"
Next you know people will be asking for proper mmap semantics on these. I'd rather see this done in userland...
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 6 lines · John M Collins
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c
latest_version"Such a scheme would let you implement things like hit counts on web sites "for free" without you having to rush out and run a CGI program as at present.
So you think this is too much work:
#!/bin/sh
echo Content-Type: application/x-tar
echo
tar cf - /latest/and/greatest
Seems to me you found a solution in search of a problem.
Eric
Hi!
Quoted 2 lines
Quoted 2 lines
latest_version.tar => "tar cf - /latest/and/greatest" latest_version.tgz => "gzip -c
latest_version"
You can do that today with uservfs.(sf.net)
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!