Program-invoking Symbolic Links?

Program-invoking Symbolic Links?

[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).

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.

-- 
John Collins Xi Software Ltd www.xisl.com

Re: Program-invoking Symbolic Links?

[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.)

On Thu, 5 Aug 2004, John M Collins wrote:

> (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.

	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 <mandrews@termfrost.org>)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at:   http://www.stearns.org
--------------------------------------------------------------------------

Re: Program-invoking Symbolic Links?

[John M Collins]

Please CC to jmc @ xisl.com

On Thursday 05 Aug 2004 15:34, William Stearns wrote:
> 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.)
>
> On Thu, 5 Aug 2004, John M Collins wrote:
> > (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.
>
> 	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

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.

-- 
John Collins Xi Software Ltd www.xisl.com

Re: Program-invoking Symbolic Links?

[viro]

On Thu, Aug 05, 2004 at 03:04:26PM +0100, John M Collins wrote:
> (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?

Re: Program-invoking Symbolic Links?

[Måns Rullgård]

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Thu, Aug 05, 2004 at 03:04:26PM +0100, John M Collins wrote:
>> (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?

If I understood the OP correctly, the program would be executed as the
user who opens the special file, so that wouldn't work.

-- 
Måns Rullgård
mru@kth.se

Re: Program-invoking Symbolic Links?

[viro]

On Thu, Aug 05, 2004 at 07:34:42PM +0200, Måns Rullgård wrote:
> > ~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.

Re: Program-invoking Symbolic Links?

[Måns Rullgård]

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Thu, Aug 05, 2004 at 07:34:42PM +0200, Måns Rullgård wrote:
>> > ~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.

Of course you're right.

> 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.

-- 
Måns Rullgård
mru@kth.se

Re: Program-invoking Symbolic Links?

[V13]

On Thursday 05 August 2004 20:57, viro@parcelfarce.linux.theplanet.co.uk 
wrote:
> On Thu, Aug 05, 2004 at 07:34:42PM +0200, Måns Rullgård wrote:
> > > ~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.

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>>

Re: Program-invoking Symbolic Links?

[Rik van Riel]

On Thu, 5 Aug 2004, John M Collins wrote:

> 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...

-- 
"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

Re: Program-invoking Symbolic Links?

[Eric Lammerts]

On Thu, 5 Aug 2004, John M Collins wrote:
> 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

Re: Program-invoking Symbolic Links?

[Pavel Machek]

Hi!

> > 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

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!