RE: File permissions problem with UniObjects for Java
Apologies for the delay. Wendy I had this same problem a while back. From memory the reason it works at the colon prompt but not from uniobjects it the umask. When you run udt it inherits it's umask from your environment. On linux I have a unidata.sh file in /etc/profile.d which sets it to 002 and the files will be created as rw-rw-r--. Other responses have explained how the umask works. A uniobjects session inherits it's environment from the unirpcd which in turn inherits this from the startud and startunirpcd. If you grep umask in $UDTBIN/startud you will find umask 022. As Charlie mentioned, the simplest fix is to alter $UDTBIN/startunirpcd so unirpcd inherits the umask you want. HTH Adrian -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: File permissions problem with UniObjects for Java
John Hester wrote: The default umask may be someplace like /etc/profile or /etc/default/login depending on your platform. Permissions on files created by OUJ logins on our system appear to be determined by the .profile of the UOJ login though. Don't know why yours would be different. The UOJ login does not have a home directory or a shell. You can't actually log in with that user id and get to a unix prompt. So no .profile for that user. I still don't get how umask could do this-- it only subtracts from the existing permissions, right? In this case I'm gaining world readable permission. (And I have only a vague grasp of how this all works, anyway.) I'll go ask on the HPUX newsgroup and see if I can find out where a default would be coming from. Thanks! -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: File permissions problem with UniObjects for Java
Wendy Smoak wrote: John Hester wrote: The default umask may be someplace like /etc/profile or /etc/default/login depending on your platform. Permissions on files created by OUJ logins on our system appear to be determined by the .profile of the UOJ login though. Don't know why yours would be different. The UOJ login does not have a home directory or a shell. You can't actually log in with that user id and get to a unix prompt. So no .profile for that user. I still don't get how umask could do this-- it only subtracts from the existing permissions, right? In this case I'm gaining world readable permission. (And I have only a vague grasp of how this all works, anyway.) umask does subtract permissions, but I think a system with no default umask specified would give full permissions for ugo. My /etc/defualt/login umask is set to 022, which is what I get with files created by non-shell processes, like those run by cron, when I don't explicitly set it differently. -John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: File permissions problem with UniObjects for Java
Off the top of my head, the default permissions and umask are 666 and 022, respectively. Subtracting the two gives you 644 or -rw-r--r--, which is what the UOJ code gave you. When you telnet, the .profile usually sets the umask to 002. Subtracting 002 from 666 gives you -rw-rw-r--, which is what you got when you logged in. So, without knowing the UOJ code, can you add umask 002 or umask ug=rw,o=r -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 11:39 AM To: U2 Users Discussion List Subject: File permissions problem with UniObjects for Java I have some UOJ code that runs a program on the database host and creates a file in _HOLD_. This is on HP-UX 11, and _HOLD_ has these permissions: drwxrws--- 2 user1live 37888 Mar 10 09:08 _HOLD_ But, when I run the UOJ program, the file gets created like this: -rw-r--r-- 1 user2live 4729 Mar 10 08:59 FFAREP.02.WSMOAK.031004 We use a single user ID for all UOJ connections, so everything created by UOJ is owned by that user. These incorrect permissions (should be -rw-rw---) cause major problems because now if the user runs the report from the telnet interface while logged in as himself, he cannot overwrite the file. He keeps getting the last one created from the UOJ code (web interface) no matter what parameters he fills in. The permissions are set properly if I log in as myself and run the same program from the colon prompt: -rw-rw 1 user3 live 3158 Mar 10 09:28 FFAREP.02.WSMOAK.031004 (And if I just use touch to create an empty file.) I'm not sure what's happening. Is there a umask somewhere that's subtracting my group write permission? But a umask could not *add* the world readable permission, so I don't think that's it. Default permissions somewhere in the OS? If I have to I can always PCPERFORM a chmod in the program that creates the file, but I'd much prefer that it work the same way from UOJ as from the colon prompt. Does anyone know what's going on and how to fix it? -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: File permissions problem with UniObjects for Java
Charlie Rubeor wrote: Off the top of my head, the default permissions and umask are 666 and 022, respectively. Subtracting the two gives you 644 or -rw-r--r--, which is what the UOJ code gave you. When you telnet, the .profile usually sets the umask to 002. Subtracting 002 from 666 gives you -rw-rw-r--, which is what you got when you logged in. So, without knowing the UOJ code, can you add umask 002 or umask ug=rw,o=r This isn't something that you'd set in Java code. It's something that's happening when UniObjects for Java connects to UniData and gets what is basically a colon-prompt session. There's an environment, but it's not the same as you get when you telnet in and your .profile executes. Does anyone know how UOJ logs in to the system? I know it connects to the unirpc daemon on 31438, but I don't know how that differs from a normal user login. I'm still not sure where the weird permissions are coming from, but I think that's going to be OS specific. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
