Maintain System Creation Date (GRX)

[Bill Campbell]

On Fri, Mar 26, 2010, John Esak wrote:
>Oh sorry, didn't mean to send that privately.
>
>But (top posted as usual)  there is a strangeness when using SYSTEM in
>Linux.. Only because I'm used to SCO (okay, yuck accepted).  Don't you
>remember the endless hours we spent in the FP Room sorting out the thing
>Dennis Malen originally found wouldn't work for something similar when he
>was constructing a Lightmail line for the SYSTEM.. .I do. Ugh. We went
>around for not hours but days.
>
>The long and short of it disregarding PFEUID and something like PFFIXROOT or
>PFROOTFIX.. I forget.  Anyway, disregarding them.  Based on the actual
>Linux, but pretty much 99% of the time. If you are a regular user and go
>down to the SYSTEM you are ID stays that user since filePro's rclerk/rreport
>are SETUID executables.  If you are root and go down to the SYSTEM you are
>converted to filePro... That bugs me. I'm already working as root, why
>should Linux force me to be some other entity?  But it does. 

This problem has been around since the early days of Profile 16+
on Tandy Xenix.  If only they had used setgid instead of setuid,
and put group write/execute permissions on everything in the FP
directories...

>That's all, no big deal except it creates havoc when creating files and then
>wanting to do something in them or remove them, etc. Really about the best
>fix is something I think Bill Randall told Jim Asman a while back... Just
>set umask to the desired mod and that gives you a little more help.
>
>My gripe is that if you are already executing the program as root and it is
>SETUID... And that program forks a shell.. You get it as filepro... Don't
>you see that as stupid?

Actually it's that way to provide some security to minimize the
damage of one has a setuid root bash or other shell, it just
might keep the cracker a bit distracted -- although probably not.

I don't remember all the details, but I think that on SCO systems
once a program has done the setuid thingy, it can't get back to
the original uid.  I suspect that one could get around this using
a proper fork/exec instead of a system call with something like
this python example (not tested so I may have arguments wrong).

import os, sys
pid = os.fork()
if not pid:
	# I am the child
	setiuid(...)
	os.execl('/bin/sh', ...)
	# raise error here since exec failed.
#}
# wait for the child to exit
os.wait(pid)

BTW, It's a common misconception that the st_ctime time of an
object on the file system is the creation time on *nix systems.
It is actually the time the status of the object changed which
includes actions like chmod, chown, and chgrp which don't change
the st_mtime (modification time) or st_atime (access time).

Using any of the stat() times to govern actions is not really
safe as ``touch'' can change the st_mtime, the utime() system
call can change st_mtime and st_atime, and file systems can be
mounted with the noatime option so that the access times are not
updated (they're pretty useless in any case if one is doing full
file system backups).

Bill
-- 
INTERNET:   bill at celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186  Skype: jwccsllc (206) 855-5792

A perpetual and unlimited debt represents deficit spending as a social
principle. It means a progressive redistribution of wealth by will of
government until there is no more fat to divide; after that comes a level
rationing of the national income. It means in the end the cheapening
of money and then inflation, whereby the middle class is economically
murdered in its sleep. In the arsenal of revolution the perfect weapon
is inflation. -- Garet Garrett, The Revolution Was