It looks good as long as your users are all part of the users group.
You probably want to look at the umask options for users as part of the
login paragraph. If a user changes a record and the files becomes
theirs, then this is bad.  I had something like this happen and I had to
fix it by setting the umask in the login paragraph.  I believe this was
for type 1 files not static and dynamic.

Im not a security expert, but I dont think there are any implications
for print applications.  I would think that as long as a user can read
the file, then they could generate a report from it.  What would be more
important is if the user has rights to the spool directory and it
doesnt sound like you're changing that, but you are changing the users
group.  Are you adding users to additional group users or are you
changing the users group from test to users.  Can the users group write
to the spool directory ?  Im not sure if this matters.

When I look at this I ask myself what does this really gain you and is
it worth doing the work (although I dont know how many files you're
dealing with).  Do you have 'others' on the computer ?  Plans for
'others' ?  Are the users all in the test group already and you have to
change the group and then add all users to that group ?  If you had to
do a lot of work and there are no 'others' on the system, then the worst
you could do is maybe screw something up and stop something that once
worked from working.  Thats my thinking - if it ant broke dont fix it
and keep it simple.  If you can try all of this out on a test system.

Ive always read that when securing a system you should make it as tight
as possible and then punch holes here and there only as needed.  I find
that myself I work backwards.  I make everything 'open' so that
everything 'works' and then I go back and tighten up things.  I think
this backward approach is more difficult.  I am fortunate enough to not
have a big security problem.  Our server only runs Universe and everyone
on it has access to every file and there are no special considerations.
So, I can get away with this 'policy', but I know it isnt the best
practice.

Anthony

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill
Sent: Wednesday, February 15, 2006 6:46 PM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] Unix Security


In the name of enhacing security, I want to change UniVerse file
rights...  

    from   -rwxrwxrwx   root   test    UV.DATA.FILE 
    to     -rwxrwx---   root   users   UV.DATA.FILE 

Will end-users be able to do their transactions?
Will the print applications work?
Are there any special considerations for UV?

Suggestions would be appreciated.

--Bill
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.9/261 - Release Date:
2/15/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.9/261 - Release Date:
2/15/2006
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to