links that behave differently per calling app?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

links that behave differently per calling app?

Caveman Al Toraboran
hi - is it possible to have some kind of fancy links that
know the name of the process that is trying to access
it, and based on its name, it links it to a file?

e.g. `ln -s X Y` will create link Y that always refers to
X whenever anyone tries to access Y.  but is it possible
to have a fancier linking that creates a linking file that
contains some kind of access list, that specifies things
like:

- if accessing process is named P1, then direct it to X1.
- if accessing process is named P2, then direct it to X2.
- ...
- if accessing process is named Pn, then direct it to Xn.
- else, default to X0.

i think if we have this, we can solve slotting in a simpler
way.  e.g. we install libs in their own non-conflicting 
locations, and then install for them such fancy sym links
with access that routes accessing processes to the right
version of the lib.

thoughts?

rgrds,
cm.

Sent with ProtonMail Secure Email.

Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Peter Humphrey-3
On Monday, 11 November 2019 04:37:17 GMT Caveman Al Toraboran wrote:
> hi - is it possible to have some kind of fancy links that
> know the name of the process that is trying to access
> it, and based on its name, it links it to a file?

Yes, it's done all the time. Have a look at, e.g., /usr/bin/rst*, which all
point to ../lib/python-exec/python-exec2, which is a python script.

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Walter Dnes
In reply to this post by Caveman Al Toraboran
On Mon, Nov 11, 2019 at 04:37:17AM +0000, Caveman Al Toraboran wrote
> hi - is it possible to have some kind of fancy links that
> know the name of the process that is trying to access
> it, and based on its name, it links it to a file?

  Short answer... YES!  Now convince the developers to use it.  Here's a
trivial example...

* Create a 2-line executable script "foo"
#!/bin/bash
echo "${0}"

* Create a symlink with the command "ln -s foo bar"

* Execute "./foo" and the output will be "./foo"

* Execute "./bar" and the output will be "./bar"

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Jack
On 11/11/19 12:38 PM, Walter Dnes wrote:

> On Mon, Nov 11, 2019 at 04:37:17AM +0000, Caveman Al Toraboran wrote
>> hi - is it possible to have some kind of fancy links that
>> know the name of the process that is trying to access
>> it, and based on its name, it links it to a file?
>    Short answer... YES!  Now convince the developers to use it.  Here's a
> trivial example...
>
> * Create a 2-line executable script "foo"
> #!/bin/bash
> echo "${0}"
>
> * Create a symlink with the command "ln -s foo bar"
>
> * Execute "./foo" and the output will be "./foo"
>
> * Execute "./bar" and the output will be "./bar"

That makes a distinction based on the name by which the script was
called, not on the name of the calling script.  Caveman Al, have I
misunderstood what your are asking for?

Jack


Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

rudi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Would this be a case for "ps"?

If you would like to know the PID of the process that calls your script you could execute "ps -o
comm= $PPID"

https://pubs.opengroup.org/onlinepubs/009604499/utilities/ps.html

Rudi

November 11, 2019 5:34 PM, "Jack" <[hidden email]> wrote:

> On 11/11/19 12:38 PM, Walter Dnes wrote:
>
>> On Mon, Nov 11, 2019 at 04:37:17AM +0000, Caveman Al Toraboran wrote
>
> hi - is it possible to have some kind of fancy links that
> know the name of the process that is trying to access
> it, and based on its name, it links it to a file?
>> Short answer... YES! Now convince the developers to use it. Here's a
>> trivial example...
>>
>> * Create a 2-line executable script "foo"
>> #!/bin/bash
>> echo "${0}"
>>
>> * Create a symlink with the command "ln -s foo bar"
>>
>> * Execute "./foo" and the output will be "./foo"
>>
>> * Execute "./bar" and the output will be "./bar"
>
> That makes a distinction based on the name by which the script was called, not on the name of the
> calling script. Caveman Al, have I misunderstood what your are asking for?
>
> Jack
-----BEGIN PGP SIGNATURE-----
Version: Keybase OpenPGP v2.1.3
Comment: https://keybase.io/crypto

wsFcBAABCgAGBQJdyq9EAAoJEO9k88vRoevdQLUP/RTw4j7pwVpehYcElbrJ1KdI
5W9Jyx2x8rr3JQz0s3YYehp/WZITKWLiIj4ho3FuHXWRVr+4ncl1s2NMJ9FR2GLV
aquB4G+6t4n0dUIiVOKXnIl9vT9fRvS3yLby77dO9mMdoU6EjUSSYFxLC1F51rpj
FjrF2wiT3aGb0lEunEF2ZGMXwoLCbRw88bfovFq4CiU5nteMBfcbp/FH0X9nyyEJ
eL8855Jojd+KZLazJEKpGQob2dzvJQ/l9KE1dLy2NUu57OSBIh20WsZoAN89G7dR
DWG70ywdivTpMmHooegpRxbMXrDZx662iSnWcERddG2vcirIisYhhlh8qgQYn83n
Q/HSvKDp/o+kkkav25TYiKUBV6nT/t6WvFbXoz8WDJKErFbMBobBD8H3mqclL4OF
3nyXVniD2dfVeR/pGu1U0iI5+kLBt+GKv7l01LhfenOF/Hsm0qAbaH+523BggCMH
Ak6/Ec3GU7qV5QNAqdFFlpvIP3VzfbTHEaDDbPfSBAENJD7GrBfUanxFtIs9LpS8
JtJKC/b/CWiK0jnAGe6yC8yqRb5qjtz60GWSFZPKVoSdwdsMlIJ4XmmLZHDtncQh
87BiEG2Tt3QobekaYqv6/fGA7g6tn9xAZWQpgpImM8kDAlLFtBr4uTa4Fq9V/hFI
qVwD3XtUKn+TD0vC+cYc
=loNt
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Poison BL.
In reply to this post by Caveman Al Toraboran
On Sun, Nov 10, 2019 at 11:37 PM Caveman Al Toraboran
<[hidden email]> wrote:
>
> hi - is it possible to have some kind of fancy links that
> know the name of the process that is trying to access
> it, and based on its name, it links it to a file?

Yes, and that's used pretty extensively in busybox. Symlinks named any
of its tools that point to it directly call into *that* tool.

> i think if we have this, we can solve slotting in a simpler
> way.  e.g. we install libs in their own non-conflicting
> locations, and then install for them such fancy sym links
> with access that routes accessing processes to the right
> version of the lib.

I'm not entirely sure about the library level. Your goal sounds like
one link to many library versions instead of many links to one
library. A symlink itself can only point at one thing, so the
filesystem level can't do that. So you would have to have a shim
library that gets loaded, then loads the version the calling process
needs... based on either an exhaustive table of the mappings of every
binary to the versions they need, or some other magic.You wouldn't be
able to just pick any version of a library and hand it back to a
process, since major versions on libraries tend to break the
interfaces they present, so you would end up having a 1:1 mapping of
any particular binary calling a singular library version. That already
happens based on the linker, and even works for less specific
versioning in many cases with symlinks from, say, libc.so.6 and
libc.so.6.2 pointing to libc.so.6.2.13 (which is actually a many links
to one library technique that's already used). To change what
interface a calling process *can* work with will require rebuilding it
against the new major version of the library, and if it's one of those
circular situations where it's part of the build process, you have to
have both the old and new library available (one of the reason slots
exist). The binary itself should contain enough detail to load the
version *it* needs already, and then should be requesting that from
the dynamic linker already...

--
Poison [BLX]
Joshua M. Murphy

Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Rich Freeman
In reply to this post by Caveman Al Toraboran
On Sun, Nov 10, 2019 at 11:37 PM Caveman Al Toraboran
<[hidden email]> wrote:
>
> i think if we have this, we can solve slotting in a simpler
> way.  e.g. we install libs in their own non-conflicting
> locations, and then install for them such fancy sym links
> with access that routes accessing processes to the right
> version of the lib.
>

I think the respondents so far haven't actually understood what you're
asking based on your example.  What follows is mainly for the purposes
of fun discussion and some awareness of what is out there, but IMO
none of this is really a great basis for a solution...

This is certainly possible for EXECUTABLES and is in fact commonly
done.  busybox is probably the most prominent example of this, and
sysvinit uses it as well (as do many others no doubt).

However, you're asking about libraries and probably files in general,
such as config files.

With a library it might be possible (though probably inadvisable) to
build a wrapper library that intercepts calls, figures out which
ABI/API to use, and then dispatches them to the appropriate
implementations.  Since it runs under the calling process it would
know what that process is.  Or you could use the following method...

For generic files such as text files an even more inadvisable approach
would be to use a bazillion FIFOs and possibly fanotify to intercept
read/writes and return the appropriate data.  However, I think FIFOs
are limited to sequential access so that is going to limit what it can
be used for.  I'm not sure at what point fanotify for permissions
blocks but you might also be able to swap out the symlink between the
call to open and the time when the file is actually opened, but that
seems likely to be subject to race conditions if you have 3 processes
trying to open the same file at the same time (even if fanotify gives
the opportunity to relink the file in time how would it know that the
process now has an open descriptor that no longer depends on the link
and that it is safe to relink for the next process).

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: links that behave differently per calling app?

Grant Taylor-2
In reply to this post by Caveman Al Toraboran
On 11/10/19 9:37 PM, Caveman Al Toraboran wrote:
> hi - is it possible to have some kind of fancy links that know the
> name of the process that is trying to access it, and based on its name,
> it links it to a file?

I've not heard of that specifically.

> e.g. `ln -s X Y` will create link Y that always refers to X whenever
> anyone tries to access Y.  but is it possible to have a fancier linking
> that creates a linking file that contains some kind of access list,
> that specifies things like:
>
> - if accessing process is named P1, then direct it to X1.
> - if accessing process is named P2, then direct it to X2.
> - ...
> - if accessing process is named Pn, then direct it to Xn.
> - else, default to X0.

However, I have heard of something that might come close to what you
what I think you're asking about.

I've never heard of support for this in Linux.  But I have heard of an
ability that /some/ other traditional Unixes have where a named sym-link
can point to a different file based on the contents of an environment
variable.

Think of it as something like this:

     ln -s /usr/arch/$ARCH/bin /usr/bin

Thus

     /usr/bin -> /usr/arch/x86/bin   # on x86

-or-

     /usr/bin -> /usr/arch/arm/bin   # on ARM

Depending on what your architecture is and thus the value of the $ARCH
environment variable.

I /think/ this was done based on environment variables and / or
something else equally consistent in the kernel.

I have no idea what this type of link is called.  But it is a well
established standard in the traditional Unix space.  Though, I think
it's seldom used.

> i think if we have this, we can solve slotting in a simpler way.
> e.g. we install libs in their own non-conflicting locations, and
> then install for them such fancy sym links with access that routes
> accessing processes to the right version of the lib.

Interesting idea.

I'd need to know more about how the links are actually implemented and
more about slots to even fathom a guess if it would work.  I'm sure it
would do something.  I just can't say if we would like what it does or not.

I question if environment variables are what's used, mainly because of
the potential volatility of the environment; different interactive
shells, different ""shells in /etc/passwd (et al.) that bypass
interactive shells, remote commands, etc.  I could envision how the
traditional environment variable might not behave as desired.

I also have concerns about the potential security implications of an end
user changing something in their interactive shell's environment, thus
altering where this type of link would point to.

> thoughts?

I would very much like to see this type of functionality come to Linux.
But I gave up hoping for it a long time ago.



--
Grant. . . .
unix || die





--
Grant. . . .
unix || die