Maintain System Creation Date (GRX)

Fairlight fairlite at fairlite.com
Fri Mar 26 22:14:54 PDT 2010


On Fri, Mar 26, 2010 at 11:47:58PM -0400, John Esak may or may not have
proven themselves an utter git by pronouncing:
> 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. 

Huh.  I can indeed confirm that via processing that just does:

SYSTEM "id > /tmp/fltid"

result:

uid=200(filepro) gid=200(filepro) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

That was starting su'd to root.  If I'm 'fairlite', it drops me back to
'fairlite'.  If I'm root, it drops me back to 'filepro'.  I just confirmed
it twice.

You know, ordinarily, obviously elevating someone to root is a bad idea.  I
figured this may be a bash issue, but apparently not.  I tried the
following tiny C program:

#include <stdio.h>

int main() {
        system("/usr/bin/id");
        exit(0);
}

Compiled that, and copied a.out to a.out2.  I left a.out just as owned root
and 755, I chowned a.out2 to filepro and made it 4711.  I ran both and got
the same output...both leaving me as root when starting as root.

I'm not sure what the mechanics actually are with fP, but this doesn't look
like a bash issue as I'd first assumed.  In fact, if I start both as
fairlite, I stay fairlite on a.out, and I'm dropped to fairlite on a.out2,
which -is- bash's doing.

This almost looks like it's rclerk doing it, but I'd have to use strace to
be even remotely sure, and...frankly I already put in more time than it's
worth to me on a Friday night.  :)

I do see the behaviour your describe, however.

> 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.

Depends what you need to do to them afterwards.  :)

> 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?

Frankly, not only yes, but "Hell yes, SIR!"  :)  

It should be easy to check uid and if it's actually zero, then don't change
euid to filepro's.  And that change has to be happening somewhere, because
uid is actually getting set.  If I didn't know better, I'd say it was
filePro itself doing this, because it doesn't match any behaviour I've ever
seen.  I suppose it's Yet Another Bash Bug, but that's hard to test without
ripping into bash's source code or replacing bash...which, again...Friday
night, games to play, back recovering from a week of agony...I think not.

Definitely screwy though.  And definitely not the behaviour I'd expect.

mark->
-- 
Audio panton, cogito singularis,


More information about the Filepro-list mailing list