ToC Home Issues Hearts Links

Issue #2, June 2005

SlackWisdom

In this issue, you will find the following materials:

What is a dev? What is a mountpoint? 

"Al. C" <no.spam.acanton@take.out.adams-blake.no.spam.com> wrote:
> I've read a ton on Linux books this past year. But two things that
> are never explained well are:
>
> What is a device? By that I mean what are the entries in /dev (like
> /dev/cdrom or /dev/fd0 etc.) I don't mean what they stand for, but
> WHAT are they?
>
> Then, what is a mountpoint? What is /mnt/cdrom mean?
>
...
> I don't understand what a device is, what a mountpoint is and what
> the relationship between them is.
>
> The books all say "In Linux everything is a file" and then they go
> off into gibberish-land... I often think the AUTHORS don't know the
> answer!

From: Floyd L. Davidson <fl...@barrow.com>
Date: Wednesday 05 January 2005 12:57:04
Groups: alt.os.linux.slackware (Original Post)

I laughed when I read that... then I read the answers you are getting. Seems I was naive to think the questions were naive.

First, the "everything is a file" is not a Linux concept, but rather was inherent in UNIX right from the beginning, where it was indeed a new idea. Your concept of what a "file" is, is too limited! (Which is one reason for the confusion.)

An Operating System provides services to "user" applications, and the idea behind "everything is a file" is to make the application's interface to everything just the same as if it were a file rather than implementing a totally distinct set of functions for each and every type of interface, which is exactly the way OS's were written prior to UNIX.

For example, we have an OS that provides "system calls" (in the C programming language the functions in Section 2 of the man pages access those services), and for files we have a basic set of functions (e.g., open(), read(), write(), lseek() and close()) to allow programs to manipulate files. That is the interface the creators of UNIX wanted to use for everything. (They did not succeed immediately in doing so, but modern unix OS's pretty much do, with a few exceptions.)

What's all that mean? Well, if we have a printer or a modem, we want to be able do IO using those open/read/write/close functions! There are other things too... networks, pipes, buffers, and for that matter processes themselves as well as the kernel itself, which can be accessed using the "file interface"!

That works because there are many types of "files" and while at the application programming level we rarely are ever much concerned with different file types, inside the kernel each of those functions that deal with files are actually doing very different things for each different type of file. Hence if your applications program wants input from a FIFO, from a disk file, and from a modem, the way the read() function is used is identical... but inside the kernel what happens is totally different. The read() function has the same name, but it executes different code for each of those "files". The whole point of the UNIX concept of "everything is a file" is to hide that difference from application programmers and users.

Whenever you do an ls command using the -l option you see a display that shows the file type as part of the string that also shows the permissions. The man page for ls says (reformatted for emphasis): 

      "The file types are as follows:

            -   for an ordinary file,
            d   for a directory,
            b   for a block special device,
            c   for a character special device,
            l   for a symbolic link,
            p   for a fifo,
            s   for a socket."

OK? Now you can see that the kernel uses "file" system calls to do several different things, depending on what "type" of file.

One of those things is access to hardware via "device special" files, the "b" and "c" types in the list above. Generally device special files are all kept in the /dev directory, and a quick check there shows how diverse this "everything is a file" concept has gotten! We can access the computer's memory, every hardware device from hard disks to printers, and a bazillion other things, in an application by using the same functions that are used to access just an "ordinary file".

Prior to UNIX, it was much more likely that an OS would provide a different system call for each type of device; which means each of the "major" device numbers used by device special files in /dev would probably have had a totally separate function for each of read(), write() and so on. It worked fine to begin with, but obviously would be way out of hand by today!

So that is what a "device" is! It is the magic hidden inside the kernel to allow one universal, simplified, method of access to anything for input/output. It is the part of the kernel which decides what the read() function, for example, will actually do when called for that particular file. A "device driver" is the code to provide the functionality. It extends the kernel's list of "file types" by providing a "file interface" for any given hardware.

Hence you can only call read() on /dev/xyz if there is a "driver" in the kernel for an xyz. And of course the driver must actually find whatever hardware it is supposed to communicate with too.

On to "mountpoint"...

Directories are one of those "different" types of files too. And a mount point is nothing other than a directory!

A mount point is a directory that is arbitrarily used as the place where a "filesystem" is attached to the directory tree. But there is nothing special about it, as any directory can be used as a mount point.

A "filesystem" is just more kernel magic used to hide messy details from application level programming. It usually provides a standardized view of "files" available on some storage device, but for example sometimes it provides a view of "files" (information) available from the kernel!

Regardless, the "mount" system call attaches the filesystem to the directory tree, which makes those "files" available via the interface discussed above. A filesystem can be mounted on any directory, and any directory that has a filesystem mounted on it is then called a "mount point".

Now, consider two ideas...

If you have a directory which contains a list of files available on one storage device, what happens if you then mount another filesystem on that particular directory? Can you access the files that were available prior to mounting the new filesystem? Are they still there? Hmmmm... (Try it!)

But another idea is actually much more interesting! The "everything is a file" concept actually means "everything that is local to this computer is a file". Things that are networked don't fit quite so well, though certainly even that is partially interfaced as a "file". (Networks aren't well adapted, but network connections, once they are set up, are.) So... what if the paradigm is change to "everything is a network"? The same people who came up with "everything is a file" have also spent a couple decades or so researching the concept of viewing everything as a network too.

Floyd L. Davidson
Ukpeagvik (Barrow, Alaska)

From: Ayaz Ahmed Khan
Newsgroups: alt.os.linux.slackware
Date: 5 Jan 2005 19:59:11 GMT (Original Post)

Device files, special files or nodes of the filesystem are names through which character and/or block devices are accessed. The kernel associates a major number, a 16-bit number as far as the 2.4 series kernels are concerned, with a device driver which provides mechanisms (and sometimes policies) that implement open, read, write, release, ioctl, and other functions which access the physical device attached. Device's or its driver's name is ignored by the kernel.

The minor number of a device driver is something the kernel doesn't need, nor use; it merely passes this value along to the driver. Within the driver, however, the minor number is used to distinguish among various instances of the same device having the same major number (and any name).

In a strict sense, the kernel doesn't read and write information from and to devices. It only provides raw resources to the devices' drivers, which in turn provide mechanisms that are used to access the device.

-- Ayaz Ahmed Khan

Why partition a hard disk? 

Dudee Bastardo wrote:
> Hi,
> Just a short question.
> If one has only one HD then is there any point of making different
> partitions for the differnt 'directories' ? Like hda2 for /home, hda3
> for /tmp etc, or is it better to use just one?

From: Lew Pitcher <lpitc...@sympatico.ca>
Date: Sat, 07 May 2005 20:07:13 -0400
Newsgroups: alt.os.linux.slackware (Original post)

It depends on your needs and how stable you want your system.

I like to use partitions for directories that should be protected during regular system use (i.e. /boot) or that I want to save if I have to reinstall the system (i.e. /usr/local and /home). But, this plan might not suit you.

Here's a list that I've compiled showing the reasons to partition. I'm sure that a rebuttal will soon be posted in reply :-) [1]

Why partition? There are many reasons:

Lew Pitcher

Master Codewright & JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

Editors' remarks:

[1] None were.

[2] A new Linux user may want to check the following guides to partitioning a hard drive, one at http://twiki.iwethey.org/ and another one at http://linuxquestions.org/.

No upgrade for aaa_base and aaa_elflibs 

On Wed, 26 Jan 2005 09:15:39 +0300,  Mikhail Zotov wrote:
> Slackware-current now has new versions of aaa_elflibs and aaa_base.
> AFAIU, there is no need to upgrade aaa_base.  But what do you do
> with aaa_elflibs?  Its slack_desk says that "this package should be
> not upgraded or reinstalled."  (To be fair, I have reinstalled it
> once in Slack-10.0.  I had to fix a number of things by hands then.)
> On the other hand, UPGRADE.TXT does not contain any warnings
> concerning upgrading aaa_elflibs.

From: Stuart Winter
Date: Wednesday 26 January 2005 13:13:25
Groups: alt.os.linux.slackware (Original post)

Here is what Pat says about aaa_elflibs (slightly edited) some time ago. I hope this helps explain the purpose of aaa_elflibs and answers the question of why it should not be upgraded.

[..] Of course, aaa_elflibs (kludgey as it is) contains a few nuggets that really aren't found anywhere else. I've also been meaning to warn people that if they see a new aaa_elflibs released that upgrading to it is a REALLY DUMB IDEA. The aaa_ packages are intended for one time installation (though reinstalling aaa_base is a lot safer than reinstalling aaa_elflibs). aaa_elflibs is mostly to provide a net for people who would otherwise install a functionally incomplete system to cut down on the amount of help people need if they do not install required packages. It wouldn't be such a bad package except that some projects (like, say CUPS, or ALSA) don't tend to increment library versions when they release new ones, so ancient ones in aaa_elflibs get copied over new ones, and things begin to mysteriously fail. Fun, huh?

I've been meaning to look at a solution, but previous attempts like staging libraries from /lib/incoming and considering if they should be installed had other problems. A nice side effect of the filename collisions is that having something listed in aaa_elflibs also prevents removing the newer library when people run around removing things at random so they can have 60GB free instead of 59GB ;-)

Continued a bit later:

Oh, and to answer the question about why it is not in UPGRADE.TXT: if you're upgrading every package in the OS, then there is no need to worry about aaa_elflibs because its library versions are identical to those contained within the main packages.

For example: 

   turrican [a] # tar ztvvf aaa_elflibs-10.1.0-i486-1.tgz | grep curses.so
   -rwxr-xr-x root/root    253584 2005-01-24 17:02:29 lib/libncurses.so.5.4
   turrican [a] # tar ztvvf ../l/ncurses-5.4-i486-2.tgz|grep curses.so
   -rwxr-xr-x root/root    253600 2004-02-17 23:22:33 lib/libncurses.so.5.4
   turrican [a] #

This is why it is not mentioned in the UPGRADE.TXT.

A short while ago, elflibs was renamed to aaa_elflibs (the name it now has) so that it would always be installed prior to any other packages. This was so that if you were installing Slackware-current then you wouldn't run into the situation in the following example:

a/aaa_elflibs contains bzip2 libraries from a/bzip2 Because the packages are installed according to their alphabetic precedence, it meant that bzip2 would be installed first. Remembering that aaa_elblibs (or 'elflibs' as it was called previously) was only updated right before a new release of Slackware, you run into the problem, or run the risk that the installation goes like this:

It was renamed 'aaa_elflibs' to work around this problem. This also explains why you should not upgradepkg aaa_elflibs without also upgrading the entire OS.

Make and its output

From: Joost Kremers
Subject: Re: Question on installing and compiling programs.
Date: 2004-11-22 13:29:25 PST
Newsgroups: alt.os.linux.slackware (Original post)

MAKE AND ITS OUTPUT
Being A Concise And Practical Tutorial On How To Read And
Interpret The Output Gleaned From The `Make' Command, Wherein Can
Be Found For The Benefit Of The Reader Two Magical Hints
Regarding The Solution Of Never-Before Encountered Problems 

John Q <joh...@hotmail.com> writes:
> make
> make  all-recursive
> make[1]: Entering directory `/home/user/downloads/g-wrap-1.3.4'
> Making all in doc
> make[2]: Entering directory `/home/user/downloads/g-wrap-1.3.4/doc'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/user/downloads/g-wrap-1.3.4/doc'
> Making all in rpm
> make[2]: Entering directory `/home/user/downloads/g-wrap-1.3.4/rpm'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/user/downloads/g-wrap-1.3.4/rpm'
> Making all in bin
> make[2]: Entering directory `/home/user/downloads/g-wrap-1.3.4/bin'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/user/downloads/g-wrap-1.3.4/bin'
> Making all in g-wrap

this is just make telling you what it's doing. you've probably run make before, and didn't do `make clean' so the object files created on the first run are still there. therefore make has nothing to do in those directories. 

> make[2]: Entering directory `/home/user/downloads/g-wrap-1.3.4/g-wrap'

now make has entered a directory where it does have to do stuff. nice thing about make: it tells you exactly what it's doing, i.e. which commands it runs, and it doesn't hide any of the output those commands give. so: 

> guile -c \
>           "(set! %load-path (cons
> \"/home/user/downloads/g-wrap-1.3.4/g-wrap/..\" %load-path))""(d
> ebug-enable 'backtrace) \
>                         (debug-enable 'debug) \
>                         (read-enable 'positions) \
>                         (use-modules (g-wrap)) \
>                         (use-modules (g-wrap gw-standard-spec)) \
>                         (gw:generate-wrapset \"gw-standard\")"

this is the command that make is executing. it's calling guile. guile, in case you don't know, is an embedable(sp) interpreter for the scheme language. scheme, in case you don't know, is a dialect of the most brilliant programming language known to man, lisp. now, guile isn't quite happy. you can tell, because it's spitting out what you're trying to give it: 

> Backtrace:
> In unknown file:
>    ?: 38* (if (or # #) (try-load-module name))
>    ?: 39  [try-load-module (ice-9 slib)]
>    ?: 40  (or (begin (try-module-linked name)) (try-module-autoload
> name) ...)
>    ?: 41* [try-module-autoload (ice-9 slib)]
>    ?: 42  (let* (# # # #) (resolve-module dir-hint-module-name #f)
> (and # #))
>     ...
>    ?: 43  (letrec ((load-file #)) (dynamic-wind (lambda () #) (lambda
> () #) ...) ...)
>    ?: 44* [dynamic-wind #<procedure #f ()> #<procedure #f ()>
> #<procedure #f ()>]
>    ?: 45* [#<procedure #f ()>]
>    ?: 46* (let ((file #)) (cond (# => #) (# => #)))
>    ?: 47  [#<procedure #f (full)>
> "/usr/share/guile/1.6/ice-9/slib.scm"]
>    ?: 48  [load-file #<primitive-procedure primitive-load> ...]
>    ?: 49* [save-module-excursion #<procedure #f ()>]
>    ?: 50  (let (# #) (dynamic-wind # thunk #))
>    ?: 51  [dynamic-wind #<procedure #f ()> #<procedure #f ()>
> #<procedure #f ()>]
>    ?: 52* [#<procedure #f ()>]
>    ?: 53* [primitive-load "/usr/share/guile/1.6/ice-9/slib.scm"]
> In /usr/share/guile/1.6/ice-9/slib.scm:
>  194: 54* (define slib-parent-dir (let (#) (if path # #)))
>  195: 55* (let ((path #)) (if path (substring path 0 ...) ...))
>  196: 56  (if path (substring path 0 ...) ...)

this is a backtrace from guile. a backtrace just shows you what the interpreter has been doing just before it encountered an error. that info may help to determine what the cause of the error was, although in this case it's not really necessary. 

> In unknown file:
>     ...
>    ?: 57  [scm-error misc-error #f ...]
>
> <unnamed port>: In procedure scm-error in expression (scm-error (quote
> misc-error) #f ...):
> <unnamed port>: Could not find slib/require.scm in
> ("/home/user/downloads/g-wrap-1.3.4/g-wrap/.."
> "/usr/share/guile/site" "/usr/share/guile/1.6" "/usr/share/guile" ".")

now guile is reporting the actual error. it seems that it is looking for a file slib/require.scm that it cannot find. slib, FYI, is the scheme library, which (i assume, i'm not actually familiar with scheme) is similar to libc, the C library. i suspect that you haven't installed it, because FWIU it is a separate package and doesn't come with guile. 

> make[2]: *** [gw-standard.c] Error 2
> make[2]: Leaving directory `/home/user/downloads/g-wrap-1.3.4/g-wrap'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/user/downloads/g-wrap-1.3.4'
> make: *** [all] Error 2

this is just make giving you an error count, and telling you in which target and in which nested level the error(s) occurred. note that make can call itself, and when make[2] encounters an error, it breaks off and tells make[1] by which it was called about this. make[1] then also breaks off. so it looks like you're seeing two errors, but in reality you're seeing one error that's being reported twice.

one important thing to keep in mind with this sort of thing (this is magical hint #1 ;-) ): read the *entire* error message and try to grok what it says. don't just skip it because you don't understand the first line. a phrase like "Could not find slib/require.scm" should be pretty self-evident, even if you haven't got the foggiest what that backtrace is all about.

and now for magical hint #2: a google search for that missing file would have led you to this post which is a reply to someone with exactly your problem, giving the solution. (which, BTW, indicates my suspicion above was correct.)

anyways, i don't know if the problems you have compiling other programs also relate to guile/slib, but if not, try the method i suggested, using the info i provided on how the output of make is structured. read the error messages carefully, looking for anything that you understand, and try to find something that may lead to a successful google search. if nothing turns up, go to the program's home page, see if there is a mailing list (there usually is) and search the archives. if that still doesn't yield anything useful, consider posting to the list. it's usually (though admittedly not always...) a better place to ask questions that are related to a specific program.

--
Joost Kremers
Life has its moments

Why shouldn't you run network apps as root? 

On Sat, 11 Dec 2004 02:08:55 -0500, Jon wrote:
> Sorry to go slightly off topic and also sorry if this seems a stupid
> and ignorant question but ... why shouldn't you run network apps as
> root and how could something like whois be exploited?

From: Newsbox <dontspa...@thanks.invalid>
Date: Sat, 11 Dec 2004 03:29:08 -0500
Subject: Re: "SRC=69.28.159."
Newsgroups: comp.os.linux.security (Original post)

No problem Jon to answer that, and it's a good question that probably many need to know the answer to. Thanks for asking !!

Even when there are no "known vulnerabilities" or "published exploits" -- of which there are very many (that probably most people are not immediately aware), even then, ...

When you run as an unpriveledged (normal) user, then any vulnerability or exploit (search zero day exploit) that may be deployed against the application, and which succeeds in running "arbitrary code", only gets to run that arbitrary code in the priviledges of the user that was running the application. If the user is not allowed to (does not have ownership of) writing system files, then, in order to compromise the system, the attacker must then deploy a second vulnerability exploit before s/he can escalate the priveledge (ownership) to change system files (much, much more difficult).

If you run as root, whoever gets in, gets everything, right off. Very bad strategy if it can be avoided. It can be avoided by running as a normal user.

I don't think whois has a vulnerability. If it doesn't, then there is no problem. But whois will run as a normal user and as such should always be run as a normal user. If in fact there were a vulnerability in whois, for example, or an exploit for the (hypothetical) vulnerability, then whomever did exploit it ( the dirty criminal!!) could access the system with the rights of whoever called the process. And a normal user doesn't have system rights, whereas root does.

...

Walt

Copyright © 2005 by The Slack World, check here for the details.
The individual articles and posts are copyrighted by their authors.

Editorial Person Wisdom Classes Tips Notes Humour Acks

BerliOS Logo