lastlog

@Acid-Duck:

so I figured ok, let's touch /var/lastlog and behold, here's the past of /var/log/secure:

lastlog_openseek: /var/log/lastlog is not a file or directory!
Try touching /var/log/lastlog instead of /var/lastlog.

-Chris

Ok I admit, I'm guilty of a typo when I typed up my log.. The thruth is I had touched the correct file.. In the last few minutes I noticed something else, now that /var/log/lastlog exists, I had some gibberish characteres that appear in it..

–-------------snip SAMPLE----------------------

^]Ã@tty0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^

------------snip----------------------------------

Erik

PS: I still get the bad file descriptor error message.

Erik

Erik,

/var/log/lastlog is what unix refers to as a 'sparse' file. This means (among other things) that trying to access it in pretty much any conventional way (open, ls, cp, etc) will yield unpredictable results. You can find more info about sparse files on the internet, but I'm fairly certain, in this case, it's purpose is for security.

I also know that UML uses sparse files for COW (copy on write).

On my RH 9.0 small install, I'm think I simply did a '>/var/log/lastlog' and everything was fine afterwards.

Hal Williams

Unless redhat is any diffrent then other distributions in the way it handles /var/log/lastlog, which I don't think it is, what you told me would be inccorrect.

Erik

Listen I appologize,

as you can see I'm profoudly confused and you're right hehe.

Erik

@hwilliams:

Erik,

/var/log/lastlog is what unix refers to as a 'sparse' file. This means (among other things) that trying to access it in pretty much any conventional way (open, ls, cp, etc) will yield unpredictable results. You can find more info about sparse files on the internet, but I'm fairly certain, in this case, it's purpose is for security.

Hmm, lastlog may be sparse because of how it's created, but that's pretty irrelevant. It most definitely has nothing to do with security.

Basically "lastlog" is a binary file, full of "struct lastlog" entries. The lastlog information for uid 'x' is at position 'x'sizeof(struct lastlog). Now, typically when uid 12345 logs in, the system will open the lastlog file, seek to 12345sizeof(struct lastlog) and write the structure data for that uid. This will probably result in a sparse file, especially if users 100->12344 have never logged in :-) If uid's 1->12345 all log in then the file will not be sparse as all datablocks will have been modified.

As you can see, the sparseness is due to how the file is written. From a user-space perspective the file can be copied, open, read etc as normal. The garbage the OP got when he tried to read lastlog is because it's a file of binary data :-)

RedHat and Fedora (and all others? Dunno) distributions come with a "lastlog" command which will convert this binary file into readable format. Security, if any, is covered by the permissions of /var/log/lastlog (which on my Fedora linode is 0400, so only root can get this information).

For what it's worth, most Unix systems do things in a similar way… AIX is, annoyingly, somewhat different!

Stephen,

Thanks for you clear explanation of the 'lastlog' file. You're saying that user 'x' is an offset (x * sizeof(struct lastlog)) into the lastlog file, thereby eliminating the need for searching and/or moving data around.

IMHO, this technique, although creative and possibly a good idea 15-30 years ago, is overkill and a bit convoluted. After all, there must be hundreds, if not thousands, of people asserting that their lastlog file has been trashed.

I understand the logic behind this may not have been for security, but it's definitely been a by-product, as the bad people are not as likely to retrieve info and/or download a file if they think the file is trashed or are confused about it's (seemingly) ever changing size and structure.

Hal Williams

PS: This particular topic is using only one or two lines per paragraph on my IE6 browser. Is there a reason for this?

@hwilliams:

Stephen,

Thanks for you clear explanation of the 'lastlog' file. You're saying that user 'x' is an offset (x * sizeof(struct lastlog)) into the lastlog file, thereby eliminating the need for searching and/or moving data around.
Correct. When you "finger xyz" it tells you when the person last logged in by looking up this information immediately in the lasttog file, as opposed to searching wtmp (which may be rotated on a monthly basis) for the last time "xyz" appears.

@hwilliams:

IMHO, this technique, although creative and possibly a good idea 15-30 years ago, is overkill and a bit convoluted. After all, there must be hundreds, if not thousands, of people asserting that their lastlog file has been trashed.
There are many files on a typical Unix system that work similarly. Personally, with 14 years commercial SA experience, I've never seen a corrupted lastlog file (SunOS, Solaris, various Linux, HPUX, various SVr2 and SVr3, various BSDs). The only way I can think corruption could occur is if a program was compiled with the wrong lastlog structure information and then tried to overwrite this file with bad data… or disk full errors, perhaps, or a 'root' level user not knowing what they are doing and breaking it manually.

@hwilliams:

I understand the logic behind this may not have been for security, but it's definitely been a by-product, as the bad people are not as likely to retrieve info and/or download a file if they think the file is trashed or are confused about it's (seemingly) ever changing size and structure.
"Security through obscurity" isn't security at all. If I was a hacker (I'm not) and I thought the file was important (potentially lists other hosts where a user may use the same password, I guess), then I'd download the file regardless of it's state. Since the structure is defined in the system include files and it's only a 5 line program to convert the file to text, and hacking tools are automated, you "just do it".

@hwilliams:

PS: This particular topic is using only one or two lines per paragraph on my IE6 browser. Is there a reason for this? It's doing that on my Mozilla as well. I'm guessing where in the thread someone broke formatting. Ah well…

@Acid-Duck:

Ok I admit, I'm guilty of a typo when I typed up my log.. The thruth is I had touched the correct file.. In the last few minutes I noticed something else, now that /var/log/lastlog exists, I had some gibberish characteres that appear in it..

–-------------snip SAMPLE----------------------

^]Ã@tty0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^

------------snip----------------------------------
That's not gibberish, that looks like perfectly fine binary data. You logged into the system on tty0, which is the console, and so the rest of the structure is full of NULLs (no remote hostname). If that's the whole file, then I'm guessing you logged in as root.

lastlog is a binary file (see earlier posting by me). Use the "lastlog" command to view it.