[gentoo-user] links that behave differently per calling app?
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](https://protonmail.com) Secure Email.
Re: [gentoo-user] links that behave differently per calling app?
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.
Re: [gentoo-user] links that behave differently per calling app?
On Mon, Nov 11, 2019 at 04:37:17AM +, 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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] links that behave differently per calling app?
On 11/11/19 12:38 PM, Walter Dnes wrote: On Mon, Nov 11, 2019 at 04:37:17AM +, 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
Re: [gentoo-user] links that behave differently per calling app?
-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" wrote: > On 11/11/19 12:38 PM, Walter Dnes wrote: > >> On Mon, Nov 11, 2019 at 04:37:17AM +, 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-
Re: [gentoo-user] links that behave differently per calling app?
On Sun, Nov 10, 2019 at 11: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? 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
Re: [gentoo-user] links that behave differently per calling app?
On Sun, Nov 10, 2019 at 11:37 PM Caveman Al Toraboran 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
Re: [gentoo-user] links that behave differently per calling app?
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