Brian:
Theoretically speaking, of course, couldn't you give an administrator
write privileges and everyone else read and execute privileges to the
VOC. If one assumes the application isn't writing anything to the VOC,
which I know is unlikely, this is doable.
But, you know, the U2 group hasn't done much to secure the dbms. You
need to be a Windows user, the user (if it's not default) has to be
loaded into the registry via UniAdmin, there's no reasonable way to
restrict access within U2 at the file level. I remember the old Pick
that had group permissions and user IDs within the dbms. That seemed to
be the way.
Anyway, implementing file security is difficult. :-(
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* br...@brianleach.co.uk
*To:* 'U2 Users List' <u2-users@listserver.u2ug.org>
*Date:* 4/4/2012 3:21 AM
*Subject:* Re: [U2] Universe: IF statements in parargraphs don't work
anymore
Jeff is right in theory though you would need to be careful whenever you run
an upgrade account.
If you really want to secure the VOC you would also need to lock out all
other forms of access such as UniObjects: you can easily create a little
VBScript to connect through with this and read/write/delete directly. And if
anyone can ever get to shell, you have the UVread, UVwrite and UVdelete
executables.
And if you make the account a SQL schema, the VOC is not a SQL table so you
can't use grant permissions.
Brian
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeff Porterfield
Sent: 03 April 2012 23:04
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Universe: IF statements in parargraphs don't work anymore
Louie Bergsagel<louiebergsagel<at> gmail.com> writes:
No, that works fine. You only need a label if you want to skip some
lines.
Turns out somebody had deleted the VOC equal sign record "=".
Which brings up a good security question, how do you prevent someone
from deleting things? Put shell around ED and DELETE?
It would be a bummer to have to make VOC read-only.
On Thu, Jun 5, 2008 at 12:53 PM, Ron Hutchings<ron_hutchings<at>
hotmail.com>
wrote:
On Line 6 don't you need to go to a label to execute a command
instead of trying to directly execute it?
-------
u2-users mailing list
u2-users<at> listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Check into the Security Subroutines section of the Administrators Guide.
1) Make a temporary copy of ED in your VOC, call it ED.BAK. This is your
backdoor in case of problems. I would also have a separate account with a
pointer to the main account's VOC. This account you can lock with a simple
paragraph that says if @LOGNAME isn't you, LOGOUT.
2) Write a security subroutine that conforms to the specs given in Chapter 8
of the Administrators guide. Catalog it in the global catalog.
2) Copy the verbs you want to secure, including ED, into your VOCLIB.
3) Change the verbs in the VOC to Remote pointers to your VOCLIB, and add
the name of your security routine to line 4. (I might suggest testing the R
pointers before applying the security routine.)
4) Once you're sure your security is working as planned, and that you can
use the ED program you've secured, then remove your back door ED.BAK.
Remember, you can still fix the VOC from your other account if you manage to
lock yourself out.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
