It is possible to mistake a configuration file for a shell script.

One source of error which I’ve observed, was even recommended in the old ‘linpopup’ package documentation.

ICYMI, “Linpopup” was a Linux extension to the Samba server, meant to allow messages to be passed directly from one computer to another on a LAN. It was based on the old “WinPopup” feature, which Microsoft discontinued with Windows XP (Service Pack 2 ? )

I think that one of the problems with the original WinPopup was, that its messages were allowed to be rich text, including URLs, which users were tricked into clicking on, because users did not recognize that pop-up windows they were getting, were in fact intended as a feature, but that these messages were eventually sent out to blocks of IP addresses as a form of spam, sometimes carrying a payload of malware.

Unlike its Windows predecessor, LinPopup only allows Plain Old Text to be sent. But this posting is not meant to describe this, as a feature of Samba. I’m intending to showcase this as an example of a type of mistake, which modern-day thinkers make when creating configuration files. In order to ready a Samba server to receive these messages, a Linux user is given the suggestion to put the following into their /etc/samba/smb.conf, near the end of their [global] section:

message command = /usr/local/bin/LinPopUp "%f" "%m" %s; rm %s

I know this, because I custom-compiled the old package, and this was stated in the documentation.

Now, it is possible to configure some other program to receive the message, which Samba leaves in the temporary file ‘%s’, as long as we remember that any message command which Samba runs, will be run as user ‘nobody’, with the privileges of user ‘nobody’. That’s not a problem. But there is a problem with this configuration line, which users ran in to, and which users had trouble pinpointing.

This is meant for a configuration file, but the above syntax would be suitable for a shell script. A configuration file will often allow for an executable program to be specified, and will even go so far as to allow command-line parameters to be passed in. But a configuration file will not go so far, as to allow two programs to be executed in sequence. That is a luxury which too many modern coders take for granted, apparently.

The two programs referred to above are

/usr/local/bin/LinPopUp

rm

In fact, this configuration mistake will pass in the semicolon, as part of the parameters to /usr/local/bin/LinPopUp , thereby mangling the ability of this program to identify the file the message is in. And then it will pass in the string “rm” as well…

What I had to do myself, was something like

message command = bash -c '/usr/local/bin/linpopup "%f" "%m" %s ; rm %s' &

The one program I’m telling Samba to run, is ‘bash’. It, in turn, can run several other programs synchronously, asynchronously, etc..

Also, it should be noted that the ‘&’ at the end of my line, is not equivalent to its use in shell scripts, where it tells a running instance of ‘bash’, to disconnect the child process immediately, and to continue running the rest of the script. My ‘&’ does not assume that ‘bash’ is already running, and appears as a parameter to ‘bash’ itself.

For all I know, ‘bash’ could simply ignore this. But I do know, that this ‘&’ does not interfere in my message command working…

Dirk

(Edit : ) And, It is up to the way the Samba server parses its configuration file, whether it expands the variables, which begin with ‘%’ , inside single quotes. It doesn’t matter that ‘bash’ would not do so.

 

Print Friendly, PDF & Email

4 thoughts on “It is possible to mistake a configuration file for a shell script.”

  1. Heya this is kinda of off topic but I was wanting to know if blogs use WYSIWYG editors or if you have to manually code with HTML.
    I’m starting a blog soon but have no coding knowledge so I wanted to get guidance from someone with experience.
    Any help would be greatly appreciated!

    1. It kind of follows from my blog itself, but you may have missed it in the shear quantity of postings. There exists WordPress.org, as well as WordPress.com. The .org version requires that you have control over a Web server, with privileges to run PHP5 scripts, as well as having certain library extensions installed to the PHP interpreter. You can find a link to it here.

      Alternatively, WordPress.com offers a paid-for, blog-hosting subscription which they manage. Either version of WordPress combines WYSIWYG editing, with the freedom for the blogger to insert his own HTML, in a two-panel view, at least with the theme I have been using. I installed WordPress.org from my package manager under Linux.

      Yet, Even though HTML is being generated for me, I still needed to adapt the configuration details to my particular computer, and this need could prove too much, for potential WordPress.org users. So, if you have zero experience with this kind of thing but have some cash, WordPress.com might be more the thing for you.

      Dirk

    2. Also, You should know, that simply to add regular blog postings to a plain Web site, isn’t sufficient for most bloggers, because search engines will not spider regular Web sites often enough, to keep up with each posting. If you use specialized software, such as WordPress.org or .com , then this also subscribes you to an update service, which will accelerate when people who do random Web searches can also find your individual posting as a search result.

      IMHO, blogging does a greater service to the community, If people find their way to one posting, as a result of a random Web search about a subject they choose. After that, they can always find their way to the blog home easily, but tellingly, people will usually only scan one posting for a quick answer to their question.

      As soon as people seem to be interested in my whole blog, for no apparent reason, it alerts me to the possibility that their comment might be insincere.

      Dirk

    3. It remains a working assumption, that Web browsers receive ‘HTML’. But it has become an outdated assumption, that each page which the browser displays, originates from an HTML file on the server, by the same name. Instead, modern sites use “CGI-scripts”, which are scripts that run on the server, to generate the HTML on-the-fly, for each view that the browser can display. WordPress.org and .com are examples of this, using the language ‘PHP’ as the server-side scripting language. It would be difficult for most users, to understand or edit such scripts, unless given exact training in doing so. Writing PHP means Programming, while writing HTML does not.

      My blog is actually stored in a database, and the PHP scripts that make up the site, render the contents of this database. To do so, the PHP extensions must also be installed, which allow MySQL access to such scripts. Among many other extensions.

      I access and edit my blog via “a Web-interface”, generated by the same scripts. Hence, if those scripts were to become mangled, this could also prevent me from posting any more updates to the blog. The fact that I am sitting directly in front of the computer that acts as a server, does not change the fact that I access it via a Web-interface.

      Dirk

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>