Can I create a user-specific hosts file to complement /etc/hosts?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












176















Is it possible to add a list of hosts that are only specific to a certain user? Perhaps a user-specific hosts file?



This mechanism should also complement the entries in the /etc/hosts file.










share|improve this question



















  • 2





    well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

    – SF.
    Dec 10 '13 at 11:07






  • 2





    If the server is remote, you might try the ~/.ssh/config file: this post.

    – aaiezza
    Jul 8 '16 at 15:47















176















Is it possible to add a list of hosts that are only specific to a certain user? Perhaps a user-specific hosts file?



This mechanism should also complement the entries in the /etc/hosts file.










share|improve this question



















  • 2





    well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

    – SF.
    Dec 10 '13 at 11:07






  • 2





    If the server is remote, you might try the ~/.ssh/config file: this post.

    – aaiezza
    Jul 8 '16 at 15:47













176












176








176


54






Is it possible to add a list of hosts that are only specific to a certain user? Perhaps a user-specific hosts file?



This mechanism should also complement the entries in the /etc/hosts file.










share|improve this question
















Is it possible to add a list of hosts that are only specific to a certain user? Perhaps a user-specific hosts file?



This mechanism should also complement the entries in the /etc/hosts file.







not-root-user hosts






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 1 '11 at 20:29









Gilles

537k12810881605




537k12810881605










asked Apr 1 '11 at 10:17









redspikeredspike

983275




983275







  • 2





    well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

    – SF.
    Dec 10 '13 at 11:07






  • 2





    If the server is remote, you might try the ~/.ssh/config file: this post.

    – aaiezza
    Jul 8 '16 at 15:47












  • 2





    well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

    – SF.
    Dec 10 '13 at 11:07






  • 2





    If the server is remote, you might try the ~/.ssh/config file: this post.

    – aaiezza
    Jul 8 '16 at 15:47







2




2





well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

– SF.
Dec 10 '13 at 11:07





well, you might instead run own nameservers, and have the user use different nameservers per user-specific resolv.conf - except creating user-specific resolv.conf appears to be exactly as difficult as making user-specific /etc/hosts.

– SF.
Dec 10 '13 at 11:07




2




2





If the server is remote, you might try the ~/.ssh/config file: this post.

– aaiezza
Jul 8 '16 at 15:47





If the server is remote, you might try the ~/.ssh/config file: this post.

– aaiezza
Jul 8 '16 at 15:47










7 Answers
7






active

oldest

votes


















121














The functionality you are looking for is implemented in glibc. You can define a custom hosts file by setting the HOSTALIASES environment variable. The names in this file will be picked up by gethostbyname (see documentation).



Example (tested on Ubuntu 13.10):



$ echo 'g www.google.com' >> ~/.hosts
$ export HOSTALIASES=~/.hosts
$ wget g -O /dev/null


Some limitations:




  • HOSTALIASES only works for applications using getaddrinfo(3) or gethostbyname(3)

  • When setuid is used libc sanitizes the environment, which means that the HOSTALIASES setting is lost. ping is setuid root (because it needs to listen for ICMP packets), so HOSTALIASES will not work with ping unless you're already root before you call ping.





share|improve this answer




















  • 11





    Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

    – Stéphane Chazelas
    May 29 '14 at 12:45






  • 2





    This doesn't seem to work on CentOS 6

    – kbolino
    Dec 1 '15 at 18:51






  • 3





    Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

    – Nuri Hodges
    Nov 10 '16 at 18:53












  • I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

    – Pryftan
    Mar 11 '18 at 0:07











  • Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

    – Nakilon
    Jan 14 at 10:27


















40














Beside the LD_PRELOAD tricks. A simple alternative that may work on a few systems would be to binary-edit a copy of the system library that handles hostname resolution to replace /etc/hosts with a path of your own.



For instance, on Linux:



If you're not using nscd, copy libnss_files.so to some location of your own like:



mkdir -p -- ~/lib &&
cp /lib/x86_64-linux-gnu/libnss_files.so.2 ~/lib


(the shared library may be located elsewhere, e.g. /lib/libnss_files.so.2)



Now, binary-edit the copy to replace /etc/hosts in there to something the same length like /tmp/hosts.



perl -pi -e 's:/etc/hosts:/tmp/hosts:g' ~/lib/libnss_files.so.2


Edit /tmp/hosts to add the entry you want. And use



export LD_LIBRARY_PATH=~/lib


for nss_files to look in /tmp/hosts instead of /etc/hosts.



Instead of /tmp/hosts, you could also make it /dev/fd//3 (here using two slashes so that the length of /dev/fd//3 is the same as that of /etc/hosts), and do



exec 3< ~/hosts


For instance which would allow different commands to use different hosts files.



If nscd is installed and running, you can bypass it by doing the same trick, but this time for libc.so.6 and replace the path to the nscd socket (something like /var/run/nscd/socket) with some nonexistent path.






share|improve this answer




















  • 10





    +1 for audacity, -1 for the shock value

    – fche
    Sep 27 '13 at 12:37






  • 6





    +1 for binary patching, -1 for security implications

    – Parthian Shot
    Jun 26 '15 at 20:28











  • @ParthianShot, what security implications?

    – Stéphane Chazelas
    Jun 27 '15 at 11:05






  • 1





    @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

    – Parthian Shot
    Jun 28 '15 at 3:26







  • 13





    @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

    – Stéphane Chazelas
    Jun 28 '15 at 7:09


















20














Private mountspaces created with the unshare command can be used to provide
a private /etc/hosts file to a shell process and any subsequent child processes started from that shell.



# Start by creating your custom /etc/hosts file
[user] cd ~
[user] cat >my_hosts <<EOF
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1 news.bbc.co.uk
EOF

[user] sudo unshare --mount
# We're now running as root in a private mountspace.
# Any filesystem mounts performed in this private mountspace
# are private to this shell process and its children

# Use a bind mount to install our custom hosts file over /etc/hosts
[root] mount my_hosts /etc/hosts --bind

[root] cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1 news.bbc.co.uk

[root] exec su - appuser

[appuser] # Run your app here that needs a custom /etc/hosts file

[appuser] ping news.bbc.co.uk
PING news.bbc.co.uk (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.026 ms
^C
--- news.bbc.co.uk ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.026/0.044/0.062/0.018 ms





share|improve this answer


















  • 3





    Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

    – killermist
    Jan 1 '16 at 22:49







  • 5





    Yep, it works, you can mount a file over another file with --bind.

    – frielp
    Jan 4 '16 at 8:12











  • Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

    – Pryftan
    Mar 11 '18 at 0:02


















5














One solution is to have each user in a separate chroot, so they can each have a separate /etc/hosts to themselves.






share|improve this answer




















  • 3





    This could be an answer, but as stated with little explanation it is more suited as a comment

    – Anthon
    Dec 10 '13 at 10:49






  • 1





    Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

    – Parthian Shot
    Jun 26 '15 at 20:31


















5














I faced the same need, so I tried libnss-userhosts, but it fails at multithreaded applications. Therefore I have written libnss-homehosts. It's very new and tested only by me. You may give a chance for it!
It supports some options in /etc/host.conf, multiple alias names, and reverse resolving (address to name).






share|improve this answer


















  • 1





    This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

    – einpoklum
    Aug 14 '17 at 9:19


















3














Placing the following in ~/.bashrc is working for me in bash. It converts the hostname in the command into an address based on entries in ~/.hosts. If ~/.hosts doesn't exist or if the hostname can't be found in ~/.hosts, the command executes as normal. This should work with the original flags of the relevant functions and regarless of where the hostname is placed relative to the flags, e.g. ping -i 0.5 host1 -c 3, works. The ~/.hosts file takes preference over any other location for finding hostnames, so if there are any dupicate hostnames, the address in ~/.hosts will be used.



$ cat ~/.bashrc 
function resolve )$/d" -e "/<$!arg>/s;^s*(S*)s*.*$;1;p;q" "$hostfile")
if [[ -n "$ip" ]]; then
command "$FUNCNAME[1]" "$@:1:$(($arg-1))" "$ip" "$@:$(($arg+1)):$#"
return
fi
fi
done
fi
command "$FUNCNAME[1]" "$@"


function ping
resolve "$@"


function traceroute
resolve "$@"



An example of ~/.hosts is given below. It follows the same format as /etc/hosts. Comments and whitespace are handled correctly.



$ cat ~/.hosts 
# addresses and hostnames
stackexchange.com se

192.168.0.1 host1 # this is host1's address
login-node.inst.ac.uk login





share|improve this answer






























    2














    Not sure if this would help you, but I came here looking for a way to add saved "hosts" somewhere that was easily accessible to only my user.



    I basically needed to be able to ssh into certain boxes on our work network, which only has one entry point.



    What I did was add aliases to my .bashrc file.



    For example, if you added:



    alias jrfbox='ssh jason@192.168.6.6' 


    at the bottom of your ~/.bashrc (~ is your home directory). Then after you logout and login again, you can type jrfbox, hit Enter, and it will connect.






    share|improve this answer




















    • 12





      If you're interesting specifically in the SSH case, you should see man ssh_config.

      – Nick
      May 6 '13 at 18:08











    • You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

      – user991710
      Mar 2 '17 at 8:51











    • @user991710 Or for that matter . ~/.bashrc

      – Pryftan
      Mar 10 '18 at 23:53









    protected by Stephen Kitt May 23 '17 at 7:06



    Thank you for your interest in this question.
    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



    Would you like to answer one of these unanswered questions instead?














    7 Answers
    7






    active

    oldest

    votes








    7 Answers
    7






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    121














    The functionality you are looking for is implemented in glibc. You can define a custom hosts file by setting the HOSTALIASES environment variable. The names in this file will be picked up by gethostbyname (see documentation).



    Example (tested on Ubuntu 13.10):



    $ echo 'g www.google.com' >> ~/.hosts
    $ export HOSTALIASES=~/.hosts
    $ wget g -O /dev/null


    Some limitations:




    • HOSTALIASES only works for applications using getaddrinfo(3) or gethostbyname(3)

    • When setuid is used libc sanitizes the environment, which means that the HOSTALIASES setting is lost. ping is setuid root (because it needs to listen for ICMP packets), so HOSTALIASES will not work with ping unless you're already root before you call ping.





    share|improve this answer




















    • 11





      Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

      – Stéphane Chazelas
      May 29 '14 at 12:45






    • 2





      This doesn't seem to work on CentOS 6

      – kbolino
      Dec 1 '15 at 18:51






    • 3





      Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

      – Nuri Hodges
      Nov 10 '16 at 18:53












    • I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

      – Pryftan
      Mar 11 '18 at 0:07











    • Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

      – Nakilon
      Jan 14 at 10:27















    121














    The functionality you are looking for is implemented in glibc. You can define a custom hosts file by setting the HOSTALIASES environment variable. The names in this file will be picked up by gethostbyname (see documentation).



    Example (tested on Ubuntu 13.10):



    $ echo 'g www.google.com' >> ~/.hosts
    $ export HOSTALIASES=~/.hosts
    $ wget g -O /dev/null


    Some limitations:




    • HOSTALIASES only works for applications using getaddrinfo(3) or gethostbyname(3)

    • When setuid is used libc sanitizes the environment, which means that the HOSTALIASES setting is lost. ping is setuid root (because it needs to listen for ICMP packets), so HOSTALIASES will not work with ping unless you're already root before you call ping.





    share|improve this answer




















    • 11





      Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

      – Stéphane Chazelas
      May 29 '14 at 12:45






    • 2





      This doesn't seem to work on CentOS 6

      – kbolino
      Dec 1 '15 at 18:51






    • 3





      Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

      – Nuri Hodges
      Nov 10 '16 at 18:53












    • I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

      – Pryftan
      Mar 11 '18 at 0:07











    • Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

      – Nakilon
      Jan 14 at 10:27













    121












    121








    121







    The functionality you are looking for is implemented in glibc. You can define a custom hosts file by setting the HOSTALIASES environment variable. The names in this file will be picked up by gethostbyname (see documentation).



    Example (tested on Ubuntu 13.10):



    $ echo 'g www.google.com' >> ~/.hosts
    $ export HOSTALIASES=~/.hosts
    $ wget g -O /dev/null


    Some limitations:




    • HOSTALIASES only works for applications using getaddrinfo(3) or gethostbyname(3)

    • When setuid is used libc sanitizes the environment, which means that the HOSTALIASES setting is lost. ping is setuid root (because it needs to listen for ICMP packets), so HOSTALIASES will not work with ping unless you're already root before you call ping.





    share|improve this answer















    The functionality you are looking for is implemented in glibc. You can define a custom hosts file by setting the HOSTALIASES environment variable. The names in this file will be picked up by gethostbyname (see documentation).



    Example (tested on Ubuntu 13.10):



    $ echo 'g www.google.com' >> ~/.hosts
    $ export HOSTALIASES=~/.hosts
    $ wget g -O /dev/null


    Some limitations:




    • HOSTALIASES only works for applications using getaddrinfo(3) or gethostbyname(3)

    • When setuid is used libc sanitizes the environment, which means that the HOSTALIASES setting is lost. ping is setuid root (because it needs to listen for ICMP packets), so HOSTALIASES will not work with ping unless you're already root before you call ping.






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 2 '17 at 10:00

























    answered Dec 10 '13 at 9:51









    pwuertzpwuertz

    1,319275




    1,319275







    • 11





      Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

      – Stéphane Chazelas
      May 29 '14 at 12:45






    • 2





      This doesn't seem to work on CentOS 6

      – kbolino
      Dec 1 '15 at 18:51






    • 3





      Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

      – Nuri Hodges
      Nov 10 '16 at 18:53












    • I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

      – Pryftan
      Mar 11 '18 at 0:07











    • Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

      – Nakilon
      Jan 14 at 10:27












    • 11





      Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

      – Stéphane Chazelas
      May 29 '14 at 12:45






    • 2





      This doesn't seem to work on CentOS 6

      – kbolino
      Dec 1 '15 at 18:51






    • 3





      Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

      – Nuri Hodges
      Nov 10 '16 at 18:53












    • I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

      – Pryftan
      Mar 11 '18 at 0:07











    • Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

      – Nakilon
      Jan 14 at 10:27







    11




    11





    Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

    – Stéphane Chazelas
    May 29 '14 at 12:45





    Note that it doesn't work if you're using nscd and is limited to hostnames without a dot.

    – Stéphane Chazelas
    May 29 '14 at 12:45




    2




    2





    This doesn't seem to work on CentOS 6

    – kbolino
    Dec 1 '15 at 18:51





    This doesn't seem to work on CentOS 6

    – kbolino
    Dec 1 '15 at 18:51




    3




    3





    Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

    – Nuri Hodges
    Nov 10 '16 at 18:53






    Late to the party, but this is the inverse of what is desired, isn't it? I think OP is looking for a similar solution to adding host-resolving entries to /etc/hosts, but one that can be done in userland without escalated privileges. (i.e. 127.0.0.1 somedomain.com)

    – Nuri Hodges
    Nov 10 '16 at 18:53














    I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

    – Pryftan
    Mar 11 '18 at 0:07





    I don't remember then but these days ping isn't a suid binary in Linux; it uses capabilities. If you run getcap /usr/sbin/ping you might see something like: /usr/bin/ping = cap_net_admin,cap_net_raw+p. And technically it's that it needs to open a raw socket rather than ICMP (but I suppose you could argue that's just semantics).

    – Pryftan
    Mar 11 '18 at 0:07













    Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

    – Nakilon
    Jan 14 at 10:27





    Despite the man says "the alias file pointed to by HOSTALIASES will first be searched for name" the priority is random and if run this wget example a dozen of times it goes wrong.

    – Nakilon
    Jan 14 at 10:27













    40














    Beside the LD_PRELOAD tricks. A simple alternative that may work on a few systems would be to binary-edit a copy of the system library that handles hostname resolution to replace /etc/hosts with a path of your own.



    For instance, on Linux:



    If you're not using nscd, copy libnss_files.so to some location of your own like:



    mkdir -p -- ~/lib &&
    cp /lib/x86_64-linux-gnu/libnss_files.so.2 ~/lib


    (the shared library may be located elsewhere, e.g. /lib/libnss_files.so.2)



    Now, binary-edit the copy to replace /etc/hosts in there to something the same length like /tmp/hosts.



    perl -pi -e 's:/etc/hosts:/tmp/hosts:g' ~/lib/libnss_files.so.2


    Edit /tmp/hosts to add the entry you want. And use



    export LD_LIBRARY_PATH=~/lib


    for nss_files to look in /tmp/hosts instead of /etc/hosts.



    Instead of /tmp/hosts, you could also make it /dev/fd//3 (here using two slashes so that the length of /dev/fd//3 is the same as that of /etc/hosts), and do



    exec 3< ~/hosts


    For instance which would allow different commands to use different hosts files.



    If nscd is installed and running, you can bypass it by doing the same trick, but this time for libc.so.6 and replace the path to the nscd socket (something like /var/run/nscd/socket) with some nonexistent path.






    share|improve this answer




















    • 10





      +1 for audacity, -1 for the shock value

      – fche
      Sep 27 '13 at 12:37






    • 6





      +1 for binary patching, -1 for security implications

      – Parthian Shot
      Jun 26 '15 at 20:28











    • @ParthianShot, what security implications?

      – Stéphane Chazelas
      Jun 27 '15 at 11:05






    • 1





      @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

      – Parthian Shot
      Jun 28 '15 at 3:26







    • 13





      @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

      – Stéphane Chazelas
      Jun 28 '15 at 7:09















    40














    Beside the LD_PRELOAD tricks. A simple alternative that may work on a few systems would be to binary-edit a copy of the system library that handles hostname resolution to replace /etc/hosts with a path of your own.



    For instance, on Linux:



    If you're not using nscd, copy libnss_files.so to some location of your own like:



    mkdir -p -- ~/lib &&
    cp /lib/x86_64-linux-gnu/libnss_files.so.2 ~/lib


    (the shared library may be located elsewhere, e.g. /lib/libnss_files.so.2)



    Now, binary-edit the copy to replace /etc/hosts in there to something the same length like /tmp/hosts.



    perl -pi -e 's:/etc/hosts:/tmp/hosts:g' ~/lib/libnss_files.so.2


    Edit /tmp/hosts to add the entry you want. And use



    export LD_LIBRARY_PATH=~/lib


    for nss_files to look in /tmp/hosts instead of /etc/hosts.



    Instead of /tmp/hosts, you could also make it /dev/fd//3 (here using two slashes so that the length of /dev/fd//3 is the same as that of /etc/hosts), and do



    exec 3< ~/hosts


    For instance which would allow different commands to use different hosts files.



    If nscd is installed and running, you can bypass it by doing the same trick, but this time for libc.so.6 and replace the path to the nscd socket (something like /var/run/nscd/socket) with some nonexistent path.






    share|improve this answer




















    • 10





      +1 for audacity, -1 for the shock value

      – fche
      Sep 27 '13 at 12:37






    • 6





      +1 for binary patching, -1 for security implications

      – Parthian Shot
      Jun 26 '15 at 20:28











    • @ParthianShot, what security implications?

      – Stéphane Chazelas
      Jun 27 '15 at 11:05






    • 1





      @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

      – Parthian Shot
      Jun 28 '15 at 3:26







    • 13





      @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

      – Stéphane Chazelas
      Jun 28 '15 at 7:09













    40












    40








    40







    Beside the LD_PRELOAD tricks. A simple alternative that may work on a few systems would be to binary-edit a copy of the system library that handles hostname resolution to replace /etc/hosts with a path of your own.



    For instance, on Linux:



    If you're not using nscd, copy libnss_files.so to some location of your own like:



    mkdir -p -- ~/lib &&
    cp /lib/x86_64-linux-gnu/libnss_files.so.2 ~/lib


    (the shared library may be located elsewhere, e.g. /lib/libnss_files.so.2)



    Now, binary-edit the copy to replace /etc/hosts in there to something the same length like /tmp/hosts.



    perl -pi -e 's:/etc/hosts:/tmp/hosts:g' ~/lib/libnss_files.so.2


    Edit /tmp/hosts to add the entry you want. And use



    export LD_LIBRARY_PATH=~/lib


    for nss_files to look in /tmp/hosts instead of /etc/hosts.



    Instead of /tmp/hosts, you could also make it /dev/fd//3 (here using two slashes so that the length of /dev/fd//3 is the same as that of /etc/hosts), and do



    exec 3< ~/hosts


    For instance which would allow different commands to use different hosts files.



    If nscd is installed and running, you can bypass it by doing the same trick, but this time for libc.so.6 and replace the path to the nscd socket (something like /var/run/nscd/socket) with some nonexistent path.






    share|improve this answer















    Beside the LD_PRELOAD tricks. A simple alternative that may work on a few systems would be to binary-edit a copy of the system library that handles hostname resolution to replace /etc/hosts with a path of your own.



    For instance, on Linux:



    If you're not using nscd, copy libnss_files.so to some location of your own like:



    mkdir -p -- ~/lib &&
    cp /lib/x86_64-linux-gnu/libnss_files.so.2 ~/lib


    (the shared library may be located elsewhere, e.g. /lib/libnss_files.so.2)



    Now, binary-edit the copy to replace /etc/hosts in there to something the same length like /tmp/hosts.



    perl -pi -e 's:/etc/hosts:/tmp/hosts:g' ~/lib/libnss_files.so.2


    Edit /tmp/hosts to add the entry you want. And use



    export LD_LIBRARY_PATH=~/lib


    for nss_files to look in /tmp/hosts instead of /etc/hosts.



    Instead of /tmp/hosts, you could also make it /dev/fd//3 (here using two slashes so that the length of /dev/fd//3 is the same as that of /etc/hosts), and do



    exec 3< ~/hosts


    For instance which would allow different commands to use different hosts files.



    If nscd is installed and running, you can bypass it by doing the same trick, but this time for libc.so.6 and replace the path to the nscd socket (something like /var/run/nscd/socket) with some nonexistent path.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Aug 14 '17 at 9:28









    einpoklum

    2,15942153




    2,15942153










    answered Dec 5 '12 at 0:16









    Stéphane ChazelasStéphane Chazelas

    305k57577931




    305k57577931







    • 10





      +1 for audacity, -1 for the shock value

      – fche
      Sep 27 '13 at 12:37






    • 6





      +1 for binary patching, -1 for security implications

      – Parthian Shot
      Jun 26 '15 at 20:28











    • @ParthianShot, what security implications?

      – Stéphane Chazelas
      Jun 27 '15 at 11:05






    • 1





      @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

      – Parthian Shot
      Jun 28 '15 at 3:26







    • 13





      @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

      – Stéphane Chazelas
      Jun 28 '15 at 7:09












    • 10





      +1 for audacity, -1 for the shock value

      – fche
      Sep 27 '13 at 12:37






    • 6





      +1 for binary patching, -1 for security implications

      – Parthian Shot
      Jun 26 '15 at 20:28











    • @ParthianShot, what security implications?

      – Stéphane Chazelas
      Jun 27 '15 at 11:05






    • 1





      @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

      – Parthian Shot
      Jun 28 '15 at 3:26







    • 13





      @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

      – Stéphane Chazelas
      Jun 28 '15 at 7:09







    10




    10





    +1 for audacity, -1 for the shock value

    – fche
    Sep 27 '13 at 12:37





    +1 for audacity, -1 for the shock value

    – fche
    Sep 27 '13 at 12:37




    6




    6





    +1 for binary patching, -1 for security implications

    – Parthian Shot
    Jun 26 '15 at 20:28





    +1 for binary patching, -1 for security implications

    – Parthian Shot
    Jun 26 '15 at 20:28













    @ParthianShot, what security implications?

    – Stéphane Chazelas
    Jun 27 '15 at 11:05





    @ParthianShot, what security implications?

    – Stéphane Chazelas
    Jun 27 '15 at 11:05




    1




    1





    @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

    – Parthian Shot
    Jun 28 '15 at 3:26






    @StéphaneChazelas Changing LD_LIBRARY_PATH to point to a directory owned by the user means any other process run by the user can use that directory to co-opt any new processes spawned by replacing libraries. And updates to libnss_files.so through the package manager (including security updates) won't be reflected in the patched version. Modifying LD_LIBRARY_PATH is generally a bad thing to recommend for other reasons, but it's also unwise because of those issues.

    – Parthian Shot
    Jun 28 '15 at 3:26





    13




    13





    @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

    – Stéphane Chazelas
    Jun 28 '15 at 7:09





    @ParthianShot, your point about missing updates is a fair point. However, for your other point, if a rogue software is running in your name, it having write access to an area in $LD_LIBRARY_PATH would be the least of your worries as it's already got write access to a lot worse and more reliable areas like your .bash*, crontab, .forward, and all configuration files by all the software you use (where it can for instance set LD_PRELOAD,LIBRARY_PATH but would typically do a lot worse)

    – Stéphane Chazelas
    Jun 28 '15 at 7:09











    20














    Private mountspaces created with the unshare command can be used to provide
    a private /etc/hosts file to a shell process and any subsequent child processes started from that shell.



    # Start by creating your custom /etc/hosts file
    [user] cd ~
    [user] cat >my_hosts <<EOF
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk
    EOF

    [user] sudo unshare --mount
    # We're now running as root in a private mountspace.
    # Any filesystem mounts performed in this private mountspace
    # are private to this shell process and its children

    # Use a bind mount to install our custom hosts file over /etc/hosts
    [root] mount my_hosts /etc/hosts --bind

    [root] cat /etc/hosts
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk

    [root] exec su - appuser

    [appuser] # Run your app here that needs a custom /etc/hosts file

    [appuser] ping news.bbc.co.uk
    PING news.bbc.co.uk (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.026 ms
    ^C
    --- news.bbc.co.uk ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 0.026/0.044/0.062/0.018 ms





    share|improve this answer


















    • 3





      Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

      – killermist
      Jan 1 '16 at 22:49







    • 5





      Yep, it works, you can mount a file over another file with --bind.

      – frielp
      Jan 4 '16 at 8:12











    • Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

      – Pryftan
      Mar 11 '18 at 0:02















    20














    Private mountspaces created with the unshare command can be used to provide
    a private /etc/hosts file to a shell process and any subsequent child processes started from that shell.



    # Start by creating your custom /etc/hosts file
    [user] cd ~
    [user] cat >my_hosts <<EOF
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk
    EOF

    [user] sudo unshare --mount
    # We're now running as root in a private mountspace.
    # Any filesystem mounts performed in this private mountspace
    # are private to this shell process and its children

    # Use a bind mount to install our custom hosts file over /etc/hosts
    [root] mount my_hosts /etc/hosts --bind

    [root] cat /etc/hosts
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk

    [root] exec su - appuser

    [appuser] # Run your app here that needs a custom /etc/hosts file

    [appuser] ping news.bbc.co.uk
    PING news.bbc.co.uk (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.026 ms
    ^C
    --- news.bbc.co.uk ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 0.026/0.044/0.062/0.018 ms





    share|improve this answer


















    • 3





      Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

      – killermist
      Jan 1 '16 at 22:49







    • 5





      Yep, it works, you can mount a file over another file with --bind.

      – frielp
      Jan 4 '16 at 8:12











    • Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

      – Pryftan
      Mar 11 '18 at 0:02













    20












    20








    20







    Private mountspaces created with the unshare command can be used to provide
    a private /etc/hosts file to a shell process and any subsequent child processes started from that shell.



    # Start by creating your custom /etc/hosts file
    [user] cd ~
    [user] cat >my_hosts <<EOF
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk
    EOF

    [user] sudo unshare --mount
    # We're now running as root in a private mountspace.
    # Any filesystem mounts performed in this private mountspace
    # are private to this shell process and its children

    # Use a bind mount to install our custom hosts file over /etc/hosts
    [root] mount my_hosts /etc/hosts --bind

    [root] cat /etc/hosts
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk

    [root] exec su - appuser

    [appuser] # Run your app here that needs a custom /etc/hosts file

    [appuser] ping news.bbc.co.uk
    PING news.bbc.co.uk (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.026 ms
    ^C
    --- news.bbc.co.uk ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 0.026/0.044/0.062/0.018 ms





    share|improve this answer













    Private mountspaces created with the unshare command can be used to provide
    a private /etc/hosts file to a shell process and any subsequent child processes started from that shell.



    # Start by creating your custom /etc/hosts file
    [user] cd ~
    [user] cat >my_hosts <<EOF
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk
    EOF

    [user] sudo unshare --mount
    # We're now running as root in a private mountspace.
    # Any filesystem mounts performed in this private mountspace
    # are private to this shell process and its children

    # Use a bind mount to install our custom hosts file over /etc/hosts
    [root] mount my_hosts /etc/hosts --bind

    [root] cat /etc/hosts
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    127.0.0.1 news.bbc.co.uk

    [root] exec su - appuser

    [appuser] # Run your app here that needs a custom /etc/hosts file

    [appuser] ping news.bbc.co.uk
    PING news.bbc.co.uk (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.026 ms
    ^C
    --- news.bbc.co.uk ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 0.026/0.044/0.062/0.018 ms






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 13 '15 at 15:11









    frielpfrielp

    21146




    21146







    • 3





      Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

      – killermist
      Jan 1 '16 at 22:49







    • 5





      Yep, it works, you can mount a file over another file with --bind.

      – frielp
      Jan 4 '16 at 8:12











    • Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

      – Pryftan
      Mar 11 '18 at 0:02












    • 3





      Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

      – killermist
      Jan 1 '16 at 22:49







    • 5





      Yep, it works, you can mount a file over another file with --bind.

      – frielp
      Jan 4 '16 at 8:12











    • Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

      – Pryftan
      Mar 11 '18 at 0:02







    3




    3





    Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

    – killermist
    Jan 1 '16 at 22:49






    Wait. I thought mount just mounted filesystems onto directories (mount points). I didn't know that a file could be mounted onto another file. Does that really work? (I am asking that seriously. That isn't sarcasm.)

    – killermist
    Jan 1 '16 at 22:49





    5




    5





    Yep, it works, you can mount a file over another file with --bind.

    – frielp
    Jan 4 '16 at 8:12





    Yep, it works, you can mount a file over another file with --bind.

    – frielp
    Jan 4 '16 at 8:12













    Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

    – Pryftan
    Mar 11 '18 at 0:02





    Just as a note to those curious: this is to do with namespaces; there are the syscalls unshare(2) and clone(2) that is part of the magic here. See also namespaces(7) and user_namespaces(7).

    – Pryftan
    Mar 11 '18 at 0:02











    5














    One solution is to have each user in a separate chroot, so they can each have a separate /etc/hosts to themselves.






    share|improve this answer




















    • 3





      This could be an answer, but as stated with little explanation it is more suited as a comment

      – Anthon
      Dec 10 '13 at 10:49






    • 1





      Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

      – Parthian Shot
      Jun 26 '15 at 20:31















    5














    One solution is to have each user in a separate chroot, so they can each have a separate /etc/hosts to themselves.






    share|improve this answer




















    • 3





      This could be an answer, but as stated with little explanation it is more suited as a comment

      – Anthon
      Dec 10 '13 at 10:49






    • 1





      Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

      – Parthian Shot
      Jun 26 '15 at 20:31













    5












    5








    5







    One solution is to have each user in a separate chroot, so they can each have a separate /etc/hosts to themselves.






    share|improve this answer















    One solution is to have each user in a separate chroot, so they can each have a separate /etc/hosts to themselves.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 10 '13 at 14:28









    Michael Mrozek

    61.4k29191211




    61.4k29191211










    answered Dec 10 '13 at 10:32









    PletiplotPletiplot

    6711




    6711







    • 3





      This could be an answer, but as stated with little explanation it is more suited as a comment

      – Anthon
      Dec 10 '13 at 10:49






    • 1





      Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

      – Parthian Shot
      Jun 26 '15 at 20:31












    • 3





      This could be an answer, but as stated with little explanation it is more suited as a comment

      – Anthon
      Dec 10 '13 at 10:49






    • 1





      Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

      – Parthian Shot
      Jun 26 '15 at 20:31







    3




    3





    This could be an answer, but as stated with little explanation it is more suited as a comment

    – Anthon
    Dec 10 '13 at 10:49





    This could be an answer, but as stated with little explanation it is more suited as a comment

    – Anthon
    Dec 10 '13 at 10:49




    1




    1





    Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

    – Parthian Shot
    Jun 26 '15 at 20:31





    Well... yeah, it's doable. Although chrooting is a pretty heavy-duty solution for this kind of thing. And brings with it its own set of issues.

    – Parthian Shot
    Jun 26 '15 at 20:31











    5














    I faced the same need, so I tried libnss-userhosts, but it fails at multithreaded applications. Therefore I have written libnss-homehosts. It's very new and tested only by me. You may give a chance for it!
    It supports some options in /etc/host.conf, multiple alias names, and reverse resolving (address to name).






    share|improve this answer


















    • 1





      This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

      – einpoklum
      Aug 14 '17 at 9:19















    5














    I faced the same need, so I tried libnss-userhosts, but it fails at multithreaded applications. Therefore I have written libnss-homehosts. It's very new and tested only by me. You may give a chance for it!
    It supports some options in /etc/host.conf, multiple alias names, and reverse resolving (address to name).






    share|improve this answer


















    • 1





      This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

      – einpoklum
      Aug 14 '17 at 9:19













    5












    5








    5







    I faced the same need, so I tried libnss-userhosts, but it fails at multithreaded applications. Therefore I have written libnss-homehosts. It's very new and tested only by me. You may give a chance for it!
    It supports some options in /etc/host.conf, multiple alias names, and reverse resolving (address to name).






    share|improve this answer













    I faced the same need, so I tried libnss-userhosts, but it fails at multithreaded applications. Therefore I have written libnss-homehosts. It's very new and tested only by me. You may give a chance for it!
    It supports some options in /etc/host.conf, multiple alias names, and reverse resolving (address to name).







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Oct 20 '16 at 14:36









    bandiebandie

    5614




    5614







    • 1





      This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

      – einpoklum
      Aug 14 '17 at 9:19












    • 1





      This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

      – einpoklum
      Aug 14 '17 at 9:19







    1




    1





    This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

    – einpoklum
    Aug 14 '17 at 9:19





    This seems like a good idea to pitch to the libnss maintainers and/or to distribution maintainers. But before that happens, users without root themselves will not be able to use it. Still, +1

    – einpoklum
    Aug 14 '17 at 9:19











    3














    Placing the following in ~/.bashrc is working for me in bash. It converts the hostname in the command into an address based on entries in ~/.hosts. If ~/.hosts doesn't exist or if the hostname can't be found in ~/.hosts, the command executes as normal. This should work with the original flags of the relevant functions and regarless of where the hostname is placed relative to the flags, e.g. ping -i 0.5 host1 -c 3, works. The ~/.hosts file takes preference over any other location for finding hostnames, so if there are any dupicate hostnames, the address in ~/.hosts will be used.



    $ cat ~/.bashrc 
    function resolve )$/d" -e "/<$!arg>/s;^s*(S*)s*.*$;1;p;q" "$hostfile")
    if [[ -n "$ip" ]]; then
    command "$FUNCNAME[1]" "$@:1:$(($arg-1))" "$ip" "$@:$(($arg+1)):$#"
    return
    fi
    fi
    done
    fi
    command "$FUNCNAME[1]" "$@"


    function ping
    resolve "$@"


    function traceroute
    resolve "$@"



    An example of ~/.hosts is given below. It follows the same format as /etc/hosts. Comments and whitespace are handled correctly.



    $ cat ~/.hosts 
    # addresses and hostnames
    stackexchange.com se

    192.168.0.1 host1 # this is host1's address
    login-node.inst.ac.uk login





    share|improve this answer



























      3














      Placing the following in ~/.bashrc is working for me in bash. It converts the hostname in the command into an address based on entries in ~/.hosts. If ~/.hosts doesn't exist or if the hostname can't be found in ~/.hosts, the command executes as normal. This should work with the original flags of the relevant functions and regarless of where the hostname is placed relative to the flags, e.g. ping -i 0.5 host1 -c 3, works. The ~/.hosts file takes preference over any other location for finding hostnames, so if there are any dupicate hostnames, the address in ~/.hosts will be used.



      $ cat ~/.bashrc 
      function resolve )$/d" -e "/<$!arg>/s;^s*(S*)s*.*$;1;p;q" "$hostfile")
      if [[ -n "$ip" ]]; then
      command "$FUNCNAME[1]" "$@:1:$(($arg-1))" "$ip" "$@:$(($arg+1)):$#"
      return
      fi
      fi
      done
      fi
      command "$FUNCNAME[1]" "$@"


      function ping
      resolve "$@"


      function traceroute
      resolve "$@"



      An example of ~/.hosts is given below. It follows the same format as /etc/hosts. Comments and whitespace are handled correctly.



      $ cat ~/.hosts 
      # addresses and hostnames
      stackexchange.com se

      192.168.0.1 host1 # this is host1's address
      login-node.inst.ac.uk login





      share|improve this answer

























        3












        3








        3







        Placing the following in ~/.bashrc is working for me in bash. It converts the hostname in the command into an address based on entries in ~/.hosts. If ~/.hosts doesn't exist or if the hostname can't be found in ~/.hosts, the command executes as normal. This should work with the original flags of the relevant functions and regarless of where the hostname is placed relative to the flags, e.g. ping -i 0.5 host1 -c 3, works. The ~/.hosts file takes preference over any other location for finding hostnames, so if there are any dupicate hostnames, the address in ~/.hosts will be used.



        $ cat ~/.bashrc 
        function resolve )$/d" -e "/<$!arg>/s;^s*(S*)s*.*$;1;p;q" "$hostfile")
        if [[ -n "$ip" ]]; then
        command "$FUNCNAME[1]" "$@:1:$(($arg-1))" "$ip" "$@:$(($arg+1)):$#"
        return
        fi
        fi
        done
        fi
        command "$FUNCNAME[1]" "$@"


        function ping
        resolve "$@"


        function traceroute
        resolve "$@"



        An example of ~/.hosts is given below. It follows the same format as /etc/hosts. Comments and whitespace are handled correctly.



        $ cat ~/.hosts 
        # addresses and hostnames
        stackexchange.com se

        192.168.0.1 host1 # this is host1's address
        login-node.inst.ac.uk login





        share|improve this answer













        Placing the following in ~/.bashrc is working for me in bash. It converts the hostname in the command into an address based on entries in ~/.hosts. If ~/.hosts doesn't exist or if the hostname can't be found in ~/.hosts, the command executes as normal. This should work with the original flags of the relevant functions and regarless of where the hostname is placed relative to the flags, e.g. ping -i 0.5 host1 -c 3, works. The ~/.hosts file takes preference over any other location for finding hostnames, so if there are any dupicate hostnames, the address in ~/.hosts will be used.



        $ cat ~/.bashrc 
        function resolve )$/d" -e "/<$!arg>/s;^s*(S*)s*.*$;1;p;q" "$hostfile")
        if [[ -n "$ip" ]]; then
        command "$FUNCNAME[1]" "$@:1:$(($arg-1))" "$ip" "$@:$(($arg+1)):$#"
        return
        fi
        fi
        done
        fi
        command "$FUNCNAME[1]" "$@"


        function ping
        resolve "$@"


        function traceroute
        resolve "$@"



        An example of ~/.hosts is given below. It follows the same format as /etc/hosts. Comments and whitespace are handled correctly.



        $ cat ~/.hosts 
        # addresses and hostnames
        stackexchange.com se

        192.168.0.1 host1 # this is host1's address
        login-node.inst.ac.uk login






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 4 '16 at 10:48









        Kyle FernandesKyle Fernandes

        312




        312





















            2














            Not sure if this would help you, but I came here looking for a way to add saved "hosts" somewhere that was easily accessible to only my user.



            I basically needed to be able to ssh into certain boxes on our work network, which only has one entry point.



            What I did was add aliases to my .bashrc file.



            For example, if you added:



            alias jrfbox='ssh jason@192.168.6.6' 


            at the bottom of your ~/.bashrc (~ is your home directory). Then after you logout and login again, you can type jrfbox, hit Enter, and it will connect.






            share|improve this answer




















            • 12





              If you're interesting specifically in the SSH case, you should see man ssh_config.

              – Nick
              May 6 '13 at 18:08











            • You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

              – user991710
              Mar 2 '17 at 8:51











            • @user991710 Or for that matter . ~/.bashrc

              – Pryftan
              Mar 10 '18 at 23:53















            2














            Not sure if this would help you, but I came here looking for a way to add saved "hosts" somewhere that was easily accessible to only my user.



            I basically needed to be able to ssh into certain boxes on our work network, which only has one entry point.



            What I did was add aliases to my .bashrc file.



            For example, if you added:



            alias jrfbox='ssh jason@192.168.6.6' 


            at the bottom of your ~/.bashrc (~ is your home directory). Then after you logout and login again, you can type jrfbox, hit Enter, and it will connect.






            share|improve this answer




















            • 12





              If you're interesting specifically in the SSH case, you should see man ssh_config.

              – Nick
              May 6 '13 at 18:08











            • You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

              – user991710
              Mar 2 '17 at 8:51











            • @user991710 Or for that matter . ~/.bashrc

              – Pryftan
              Mar 10 '18 at 23:53













            2












            2








            2







            Not sure if this would help you, but I came here looking for a way to add saved "hosts" somewhere that was easily accessible to only my user.



            I basically needed to be able to ssh into certain boxes on our work network, which only has one entry point.



            What I did was add aliases to my .bashrc file.



            For example, if you added:



            alias jrfbox='ssh jason@192.168.6.6' 


            at the bottom of your ~/.bashrc (~ is your home directory). Then after you logout and login again, you can type jrfbox, hit Enter, and it will connect.






            share|improve this answer















            Not sure if this would help you, but I came here looking for a way to add saved "hosts" somewhere that was easily accessible to only my user.



            I basically needed to be able to ssh into certain boxes on our work network, which only has one entry point.



            What I did was add aliases to my .bashrc file.



            For example, if you added:



            alias jrfbox='ssh jason@192.168.6.6' 


            at the bottom of your ~/.bashrc (~ is your home directory). Then after you logout and login again, you can type jrfbox, hit Enter, and it will connect.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 28 at 19:55









            j.aevyz

            33




            33










            answered Jul 18 '12 at 4:38









            JasonJason

            421148




            421148







            • 12





              If you're interesting specifically in the SSH case, you should see man ssh_config.

              – Nick
              May 6 '13 at 18:08











            • You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

              – user991710
              Mar 2 '17 at 8:51











            • @user991710 Or for that matter . ~/.bashrc

              – Pryftan
              Mar 10 '18 at 23:53












            • 12





              If you're interesting specifically in the SSH case, you should see man ssh_config.

              – Nick
              May 6 '13 at 18:08











            • You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

              – user991710
              Mar 2 '17 at 8:51











            • @user991710 Or for that matter . ~/.bashrc

              – Pryftan
              Mar 10 '18 at 23:53







            12




            12





            If you're interesting specifically in the SSH case, you should see man ssh_config.

            – Nick
            May 6 '13 at 18:08





            If you're interesting specifically in the SSH case, you should see man ssh_config.

            – Nick
            May 6 '13 at 18:08













            You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

            – user991710
            Mar 2 '17 at 8:51





            You do not have to log out and back in again to reload ~/.bashrc, simply do source ~/.bashrc.

            – user991710
            Mar 2 '17 at 8:51













            @user991710 Or for that matter . ~/.bashrc

            – Pryftan
            Mar 10 '18 at 23:53





            @user991710 Or for that matter . ~/.bashrc

            – Pryftan
            Mar 10 '18 at 23:53





            protected by Stephen Kitt May 23 '17 at 7:06



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?


            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay