Re: [9fans] Poorly created user

[akumar@sounine.nanosouffle.net]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

Ah,

So, upon the suggestions of Erik and Steve, I took up the task of just
trying to regain this user's dignity (permissions, recognition).  As
hostowner, I copied /adm/users to a personal DIR, removed the line for
that user, then went into fscons, and ran
  users -r /path/to/copied/adm/users
  uname user user
and upon checking, the newly created home DIR (which is the only thing
I _was_ able to remove as host owner) was the user's sans parentheses:
    d-rwxrwxr-x M 282 user user 0 Nov 6 15:24 /usr/user
and upon re-enabling the user's account, logging in through drawterm
and running /sys/lib/newuser (as that user), all the files within the
user's home DIR were now appropriately owned by user.  However, the
previously created /cron/user and /mail/box/user DIRs and files were
still not accessible to this user -- what action would you suggest I
take with this?
As per the reasoning and analysis, I explained to another Plan 9 mate
(mycroftiv) that when I initially created this user, after running
auth/changeuser, I immediately logged into its account via `cpu' and
ran /sys/lib/newuser that way (as opposed to logging into the user's
account freshly, i.e., via drawterm).  mycroftiv speculates:
 "i think the stage of going through cpu WILL throw off general auth
  stuff in plan9 unless you take the step of mounting your auth stuff

  iirc you generally need to do auth/keyfs within your cpu environment
  to get things setup as a minimum".
If you have other ideas regarding this, I'm more than interested in
reaching a reasonable conclusion.


Regards

[-- Attachment #2: Type: message/rfc822, Size: 1435 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: akumar@sounine.nanosouffle.net
Subject: Re: [9fans] Poorly created user
Date: Thu, 6 Nov 2008 17:18:52 -0500
Message-ID: <3373734608927206e6f52884b0c12b13@quanstro.net>

> Thank you for taking the time to run such a trial test.
>
> What do you think would be the best course of action following
>  fsys main open -A ?
> Delete all files owned by user and remove user from the FS user table?
> Then perhaps recreate the user?
> Or instead, just look around for what might be "amiss" (not sure where
> to start)? (I'm not sure where the user information is searched for by
> the system other than the user table -- what else could possibly affect
> it?)

removing users from the user table is not a good idea
on a filesystem intended to be used with a worm.

if it were my system, i'd figure out what the problem is
before proceeding.  either you've found a bug in fossil,
or there's some sort of misunderstanding.

/adm/users should be a good place to start.

- erik