Re: Parsing Login Scripts For Variable Assignment

Well, reliably "examining" a program like this for its behavior is tantamount to solving the halting problem (read: impossible).

Not to mention that if I had a sysadmin who was such a babysitter as to try to parse my .profile for environment vars deemed "unsuitable", I'd probably start screwing wiht 'em just for the sake of pissing them off.

Maybe a better way of dealing with it is to validate that everyone's profiles' last line is something like:

source /etc/cleanup_profile
[download]

which, itself, just parsed PATH, and pulled out "." if it was there.

Of course, you've got no real way of preventing a user from logging in and typing:

[me@host me]$ PATH="$PATH:."
[me@host me]$
[download]

------------
:Wq
Not an editor command: Wq

Comment on Re: Parsing Login Scripts For Variable Assignment Select or Download Code

Replies are listed 'Best First'.
Re: Re: Parsing Login Scripts For Variable Assignment by holo (Monk) on Dec 08, 2003 at 22:17 UTC
There is a way to detect even that! See my reply above. This can be overriden as well by executing another shell manually I know but that's overkill.	[reply]
Re: Re: Parsing Login Scripts For Variable Assignment by DaveH (Monk) on Dec 09, 2003 at 09:42 UTC
Of course, you've got no real way of preventing a user from logging in and typing: `[me@host me]$ PATH="$PATH:." [me@host me]$` [download] The quickest way of stopping them doing this (again) is to do this: `[root@host /]# cat > ~me/sl <<EOF rm -rf ~me EOF` [download] Trial by fire... of course, nice sysadmins would back their home directory up first. ;-) Disclaimer: don't try this at home kids! Playing with rm without adult supervision is dangerous. Cheers, -- Dave :-) $q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print	[reply] [d/l] [select]