Bug in bash of normaal gedrag?

[Gertjan]

Ik kwam vanochtend het volgende wazige tegen:

code:

office1:/etc# ls -ld nagios
lrwxrwxrwx  1 root root 19 2006-05-24 17:14 nagios -> /etc/shared/nagios/

office1:/etc# ls -l nrpe.local.cfg
-rw-r-----  1 nagios root 193 2006-06-15 16:48 nrpe.local.cfg

office1:/etc# cd nagios

office1:/etc/nagios# cat ../nrpe.local.cfg
cat: ../nrpe.local.cfg: No such file or directory

office1:/etc/nagios# cat /etc/nrpe.local.cfg
command[check_blaat]=/usr/lib/nagios/plugins/check_blaat

Met andere woorden: in /etc staat een symlink 'nagios' naar /etc/shared/nagios. In /etc bevindt zich ook het bestand 'nrpe.local.cfg'. Vanuit de directory /etc/nagios kan ls niet bij ../nrpe.cfg, omdat hij die zoekt in /etc/shared/nagios/../nrpe.local.cfg'. Bash vindt hem echter wel, want vanuit /etc/nagios werkt tab-completion wel. De $PWD staat op dat moment ook goed:

code:

office1:/etc/nagios# echo $PWD
/etc/nagios

Heeft iemand enig idee of dit 'by design' is, of dat een bug is, en zoja: waar? Waarom vindt bash wel dat ../nrpe.local.cfg bestaat, terwijl elke willekeurige applicatie (ls, cat ...) het bestand niet ziet.

Extra info:

Distro: Debian Sarge

code:

office1:/etc/nagios# bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)

[ Voor 3% gewijzigd door Gertjan op 19-06-2006 10:19 ]

[Paultje3181]

klinkt als kenmerkend hackgedrag... Een echo dat /etc/passwd kopieert? En een programma dat niet zichtbaar is voor andere programma's?

Ik zou eens gaan zoeken op rootkits...

[0xDEADBEEF]

Uit man ls:

getconf PATH_RESOLVE determines how symbolic links are handled. This can be explicitly overridden by the --logical , --metaphysical, and --physical options below. PATH_RESOLVE can be one of:
logical
Follow all symbolic links.
metaphysical
Follow command argument symbolic links, otherwise don't follow.
physical
Don't follow symbolic links.

-L, --logical|follow
Follow symbolic links. The default is determined by getconf PATH_RESOLVE.
-H, --metaphysical
Follow command argument symbolic links, otherwise don't follow. The default is determined by getconf PATH_RESOLVE.
-P, --physical
Don't follow symbolic links. The default is determined by getconf PATH_RESOLVE.

'n Follow-up of dit de oplossing is verwacht ik wel

[xzenor]

Paultje3181 schreef op maandag 19 juni 2006 @ 10:28:
klinkt als kenmerkend hackgedrag... Een echo dat /etc/passwd kopieert? En een programma dat niet zichtbaar is voor andere programma's? Ik zou eens gaan zoeken op rootkits...

Heb je de post wel gelezen?

Volgens mij is het wel gewoon normaal gedrag..
Maar is het alleen in bash? Heb je toevallig ook dezelfde actie in sh of csh geprobeerd misschien?

[Gertjan]

0xDEADBEEF schreef op maandag 19 juni 2006 @ 10:30:
Uit man ls:

[...]

'n Follow-up of dit de oplossing is verwacht ik wel

Helaas:

code:

office1:/etc/nagios# ls -L ../nrpe.local.cfg
ls: ../nrpe.local.cfg: No such file or directory
office1:/etc/nagios# ls -H ../nrpe.local.cfg
ls: ../nrpe.local.cfg: No such file or directory

Op zich denk ik ook niet dat het 'probleem' bij ls ligt, want cat doet het bijvoorbeeld ook niet.

possamai schreef op maandag 19 juni 2006 @ 10:33:
Volgens mij is het wel gewoon normaal gedrag..
Maar is het alleen in bash? Heb je toevallig ook dezelfde actie in sh of csh geprobeerd misschien?

Nee, zo te zien is het niet alleen bash, maar ook dash:

code:

office1:/etc/nagios# dash
\h:\w$ cd /etc/nagios
\h:\w$ cat ../nrpe.local.cfg
cat: ../nrpe.local.cfg: No such file or directory
\h:\w$ cat /etc/nrpe.local.cfg
command[check_blaat]=/usr/lib/nagios/plugins/check_blaat

Ik kan me eigenlijk niet voorstellen dat normaal gedrag is, omdat bash via tab-completion de file wel vindt, maar de file daarna bij het uitvoeren van het commando niet gevonden wordt.

[mithras]

Gertjan schreef op maandag 19 juni 2006 @ 11:05:
Ik kan me eigenlijk niet voorstellen dat normaal gedrag is, omdat bash via tab-completion de file wel vindt, maar de file daarna bij het uitvoeren van het commando niet gevonden wordt.

Maar tabcompletion voor scripts werkt toch alleen bij permissie om die file te executen? En bij nrpe.local.cfg heeft niemand execute-rechten, dus werkt tabben niet Laat maar, niet goed gelezen

[ Voor 5% gewijzigd door mithras op 19-06-2006 11:15 ]

[Gertjan]

Is er nu niemand die hier iets zinnigs over kan zeggen? Het is in elk geval erg makkelijk te reproduceren, en ik heb op alle machines die ik getest heb (allen Debian Sarge) er last van.
Of ben ik de enige die dit gedrag erg raar vindt?

[CyBeR]

Twee dingen:

a) dit is onafhankelijk van bash (cat geeft de error)
b) dit is normaal gedrag

Je zit namelijk (voor cat, bash is het daar niet mee eens omdat jij net hebt aangegeven in /etc/nagios te willen zitten) niet in /etc/nagios, maar in /etc/shared/nagios. Vanaf daar gezien bestaat ../<file> niet, omdat die in ../../<file> staat.

[ Voor 22% gewijzigd door CyBeR op 21-06-2006 10:41 ]

[Verwijderd]

Paultje3181 schreef op maandag 19 juni 2006 @ 10:28:
[...]
Ik zou eens gaan zoeken op rootkits...

Tuurlijk ....

Voor de rest is dit afhankelijk van of je applicatie wel of niet symlinks volgt. Op het moment dat deze het wel doet (bash bv) dan werkt het zoals verwacht. Applicaties die dat niet doen geven een foutmelding. Geen bug, gewoon applicaties die (expliciet of impliciet) geen symlink check doet ... Zie ook de opmerking van 0xDEADBEEF en CyBeR

[frim]

laat maar, zie bovenstaande puntjes

[ Voor 93% gewijzigd door frim op 21-06-2006 10:45 ]

[Gertjan]

CyBeR schreef op woensdag 21 juni 2006 @ 10:40:
Twee dingen:

a) dit is onafhankelijk van bash (cat geeft de error)
b) dit is normaal gedrag

Je zit namelijk (voor cat, bash is het daar niet mee eens omdat jij net hebt aangegeven in /etc/nagios te willen zitten) niet in /etc/nagios, maar in /etc/shared/nagios. Vanaf daar gezien bestaat ../<file> niet, omdat die in ../../<file> staat.

Ik snap beide punten, en ik snap ook dat niet bash maar cat/ls/whatever de foutmelding geeft als ze symlinks niet volgen.
Wat ik echter niet snap, is dat bash die symlink wel volgt (tab-completion), maar vervolgens niet het echte pad naar het bestand doorgeeft aan het process. Vandaar dat ik het nog steeds raar gedrag vindt.

[decramy]

hoe heb je de link (/etc/nagios -> /etc/shared/nagios) aangemaakt?

_Nagios

[CyBeR]

Gertjan schreef op woensdag 21 juni 2006 @ 12:33:
[...]


Ik snap beide punten, en ik snap ook dat niet bash maar cat/ls/whatever de foutmelding geeft als ze symlinks niet volgen.
Wat ik echter niet snap, is dat bash die symlink wel volgt (tab-completion), maar vervolgens niet het echte pad naar het bestand doorgeeft aan het process. Vandaar dat ik het nog steeds raar gedrag vindt.

Bash kan ook wel symlinks expanden, maar als jij op de commandprompt tegen app X zegt '../foo' dan maakt bash daar niet '../../foo' van. Want dat zei je niet.

[ Voor 4% gewijzigd door CyBeR op 21-06-2006 14:48 ]

[Sendy]

Juist, en bash haalt gewoon een handig trukje uit. Als jij naar een directory cd't en direct terug cd't, dan verwacht je weer terug te zijn in de directory waar je vandaan kwam.

Als nu de eerste dir een symlink naar een andere dir is en bash onthoud niet dat je via een symlink kwam krijg je dus dat een cd heen en terug niet terugkomt waar jij het verwacht.

edit:

Voorbeeld:

dir1/dir2/dir3/
dir1/symlink -> dir1/dir2/dir3

dir1$ cd symlink
dir1/symlink$ cd ..
dir1$ pwd
dir1

dir1$ cd -P symlink
dir1/dir2/dir3$ cd ..
dir1/dir2$ pwd
dir1/dir2

[ Voor 36% gewijzigd door Sendy op 21-06-2006 16:00 ]

[SA007]

csh heeft het probleem niet:

Tcsh:

# pwd
/etc
# cd blaat
# pwd
/etc/test/blaat

Bash wel:

Bash:

Argon etc # pwd
/etc
Argon etc # cd blaat/
Argon blaat # pwd
/etc/blaat

/etc/blaat is een softlink naar /etc/test/blaat
Draai btw gentoo

[Gertjan]

It keeps getting weirder and weirder. Is dit ook normaal gedrag volgens jullie?

Ik heb in een directory, /etc/shared een aantal directories, waaronder 'apache' en 'spamassassin':

code:

office1:/etc/shared# ls -l
total 156
drwxr-xr-x  3 root   root     12288 2006-07-13 09:33 apache
drwxr-xr-x  2 root   root       4096 2006-05-31 12:18 spamassassin

Daarnaast heb ik in /etc ook een directory 'apache', maar geen 'spamassassin'.

We gaan uit van wat ik hierboven eerder beschreven heb: /etc/nagios is een symlink naar /etc/shared/nagios.

code:

office1:/etc/nagios# pwd
/etc/nagios

En nu komt het:

code:

office1:/etc/nagios# cd ../apache
office1:/etc/apache#

maar ook:

office1:/etc/nagios# cd ../spamassassin
office1:/etc/shared/spamassassin

bij ../apache vindt hij een apache in /etc, dus cd't hij daarheen. Bij ../spamassassin is er geen /etc/spamassassin, maar wel een /etc/shared/spamassassin, dus cd't hij daarheen.

Dit is toch niet consistent?

[JeroenE]

bij ../apache vindt hij een apache in /etc, dus cd't hij daarheen. Bij ../spamassassin is er geen /etc/spamassassin, maar wel een /etc/shared/spamassassin, dus cd't hij daarheen.

Dit is toch niet consistent?

Bash kijkt eerst of hij een dir kan vinden die via de naamgeving van de symbolic link te bereiken is. Blijkbaar kijkt hij -als dat niet lukt- of het wel kan via het 'echte' pad. Dat hij dat laatste ook zou doen had ik niet verwacht.

Bash kan trouwens ook via een CDPATH variabele nog een andere directory vinden..

Overigens vind ik wel dat wanneer je het niet fijn vind dat je niet precies weet waar je bent dat je dan dan geen symbolic links moet maken van je directories, of "cd -P nagios" gebruiken (of set -P of opstarten met --posix).

[kenneth]

SA007 schreef op woensdag 21 juni 2006 @ 18:09:
csh heeft het probleem niet:

En doe het nu eens met /bin/pwd ?