| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
RE: ID Command Fails Consistently in SFU 3.0
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 RE: ID Command Fails Consistently in SFU 3.0 - Apr. 26, '04, 5:09:17 PM
|
|
|
markfunk
Posts: 673
Joined: Mar. 31, '03,
Status: offline
|
Umm, you did a "chmod 755" on what directory ?
And when you did, then /bin/id no longer crashes the subsystem ?
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 26, '04, 5:20:43 PM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
My worry (and I think Mark's too) is that this may crop up again.
Something more has to be involved. The subsystem is essentially
running as "god" and a file getting it's permission changed should
cause it to crash.
BTW the 755 should be 775.
I'd recommend actually running the program that will fix all of the
permissions on all of the files correctly. There may be more lurking
that will trip something up. If you look on the CD you should see
a program called "fixperms.exe" (SFU3_0/setup on the 3.0 CD).
Run that.
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 26, '04, 5:21:54 PM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
sorry that should read "...should not cause it to crash."
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 26, '04, 8:10:27 PM
|
|
|
markfunk
Posts: 673
Joined: Mar. 31, '03,
Status: offline
|
Actually, no. Do _not_ run fixperms.exe.
Fixperms.exe is to run _only_ if you are trying to upgrade or uninstall
all Interix components and the uninstaller fails with a permission denied
type message.
This is a program of "last resort" to fix an inherit design flaw (ie. "feature") in MSI.
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 27, '04, 12:52:24 AM
|
|
|
Celestial
Posts: 16
Joined: Apr. 22, '04,
Status: offline
|
I ran the command I believe at the default directory when you run Korn shell. Honestly, I was at the peak of a cold and I was a little loopy at the time.
or I changed to the /bin directory and ran it. I will wait for the UNIX SA to run his script and see if it runs before I run the chmod 775.
There is one thing I forgot to tell you when the system crashes the posxx.exe crashes with an "Access Violation"
there is nothing in the UNIX log or in Event Viewer when this happens. The SA uninstalled and reinstalled SFU on the server BEFORE I ran this command.
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 29, '04, 11:48:45 PM
|
|
|
Celestial
Posts: 16
Joined: Apr. 22, '04,
Status: offline
|
The Unix SA has not tried his script yet so I cannot give you an update of what happened but I have a thought I wanted to share with you about this.
The problem as I see it had to do with the Interix subsystem not being able to enumerate domain accounts. I only had one account to test with so I cannot say if it was all accounts or just the dfutter account. Now you guys have told me that changing the rights within the Interix subsystem should not have done anything and I have a question.
Is it possible that while my command did not alter permissions in any significant way could it have forced the Interix subsystem to "resynchronize" its security subsystem with the NT security subsystem? Also could the order of installation cause something to break for instance...
Installing the SFU first then joining a domain or joining a domain first then installing SFU.
Just an idea that passed my mind. Please let me know if it makes absoloutely no sense.
|
|
|
|
|
RE: ID Command Fails Consistently in SFU 3.0 - Apr. 30, '04, 12:36:45 AM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
The subsystem runs as the user SYSTEM. SYSTEM has specific
rights and privileges. Certain actions are performed by the
subsystem while being SYSTEM. However, for most security related
actions (file perms, etc.) the subsystem impersonates the user
that the requesting process is running as. The same happens with
Win32 too. This is done using the process token (which was assigned
with the blessing of the security system).
There is really only one security subsystem that's used for checking.
This allows everything to be uniformly applied.
If the subsystem crashed it would be for the same sort of reason that
other programs do. Something happened that caused things to go odd.
What that is, of course, we can't say because we don't know.
Personally just the perm change on the file making things "okay" seems
unusual to me. It's more confusing than clarifying frankly.
There may be something in your environment (network, domain or computers)
that could be playing a role too. Someone posted on a different issue
about problems the Cisco security program was creating recently. It was
a new reason for problems that I hadn't seen before. So there might be
something "in left field" playing a part.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
