sh: /var/tmp/sh7877.13: Cannot create the specified file.

[samadulhaq]

Hi all,

We are facing the following error upon login;

"sh: /var/tmp/sh7877.13: Cannot create the specified file.
[oracle@xxxx][oracle]>"

background of this system, chown / chmod 777 was run by mistake on /usr. It was later fixed by going to single user.

any help in this regard will be appreciable, looking forward for your helpful response.

Regards
Samad

[Torsten.]

>> It was later fixed by going to single user.

Sure it is fixed?

I don't think so.

What have you done to fix it?

[samadulhaq]

Since im not system administrator, i don't know how exactly it was fixed. But i have provided the system team the following links, right after i realized i messed up with the system. 

After the incident, no user including root could log in.

https://community.hpe.com/t5/System-Administration/unable-to-logon-to-the-server-for-all-users/td-p/4328392

https://community.hpe.com/t5/System-Administration/HPUX-11i-how-to-check-for-correct-system-file-permissions/m-p/5075303#M439435

Here is current uptime in multiuser;

[oracle@xxxx][oracle]>uptime
1:31pm up 1 day, 1:20, 5 users, load average: 0.00, 0.00, 0.00

Is there any way we can verify if something wasn't fixed ?

Regards
Samad Ul Haq

[samadulhaq]

After every new session created by oracle on both systems, below is the output of tail -400f /var/adm/syslog/syslog.log

Both system are on same release i.e. Release:   HP-UX B.11.31

System 1 (entirely healthy no issue ever reported)

Nov 15 18:10:33 abc sshd[17206]: SSH: Server;Ltype: Version;Remote: 10.x.x.180-57518;Protocol: 2.0;Client: SecureCRT_6.7.1 (x64 build 188) SecureCRT
Nov 15 18:10:33 abc sshd[17206]: SSH: Server;Ltype: Kex;Remote: 10.x.x.180-57518;Enc: aes256-ctr;MAC: hmac-sha1;Comp: none [preauth]
Nov 15 18:10:33 abc sshd[17206]: SSH: Server;Ltype: Authname;Remote: 10.x.x.180-57518;Name: oracle [preauth]
Nov 15 18:10:33 abc sshd[17206]: Accepted password for oracle from 10.x.x.180 port 57518 ssh2

System2 (recovered)
Nov 15 18:09:13 xxx sshd[8001]: SSH: Server;Ltype: Version;Remote: 10.x.x.180-57503;Protocol: 2.0;Client: SecureCRT_6.7.1 (x64 build 188) SecureCRT
Nov 15 18:09:13 xxx sshd[8001]: SSH: Server;Ltype: Kex;Remote: 10.x.x.180-57503;Enc: aes256-ctr;MAC: hmac-sha1;Comp: none [preauth]
Nov 15 18:09:13 xxx sshd[8001]: SSH: Server;Ltype: Authname;Remote: 10.x.x.180-57503;Name: oracle [preauth]
Nov 15 18:09:13 xxx sshd[8001]: Accepted password for oracle from 10.x.x.180 port 57503 ssh2

Regards
Samad 

[Steven Schweda]

> "sh: /var/tmp/sh7877.13: Cannot create the specified file.

> [...] chown / chmod 777 was run by mistake on /usr. [...]

   Ok.  Considering how likely bad permissions would be on this system,
have you looked at the permissions of "/var/tmp"?

      ls -ld /var/tmp

What about "sh"?

> [...] the system team [...]

   Have you asked "the system team" about this problem?

> Is there any way we can verify if something wasn't fixed ?

   Compare permissions with those on some system which has not been
damaged (by some fool)?

[Patrick Wallek]

What are the permissions on the /var/tmp directory?

# ll -d /var/tmp

Is there already a file called "sh7877.13" in the /var/tmp directory?  If so, you might have to delete it.

# ll /var/tmp/sh7877.13

[samadulhaq]

Im the "fool" who did it, please find below the output required

[oracle@healthynode][database]>ll -d /var/tmp
drwxrwxrwt 10 root root 8192 Nov 15 18:47 /var/tmp
[oracle@healthynode][database]>ls -ld /var/tmp
drwxrwxrwt 10 root root 8192 Nov 15 18:47 /var/tmp

[oracle@recoverednode][oracle]>ll -d /var/tmp
drwxrwxr-t 8 root root 8192 Nov 15 19:22 /var/tmp

[oracle@recoverednode][oracle]>ls -ld /var/tmp
drwxrwxr-t 8 root root 8192 Nov 15 19:22 /var/tmp

Regards
Samad 

[samadulhaq]

---

@Patrick Wallek wrote:

What are the permissions on the /var/tmp directory? 

Is there already a file called "sh7877.13" in the /var/tmp directory?  If so, you might have to delete it.

# ll /var/tmp/sh7877.13

---

shxxxx is variable , it changes with every new session.

Here is example of current session:

Confidential computer software. Valid license from HP required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.

sh: /var/tmp/sh29823.13: Cannot create the specified file.

[oracle@recoverednode][oracle]>ll /var/tmp/sh29823.13
/var/tmp/sh29823.13 not found.

Regards
Samad

[Patrick Wallek]

On the "recoverednode" system, you /var/tmp/permissions are rwxrwxr-t. and ownership is root:root.  Based on that, nobody but root, or someone in the root group, will be able to create a file.

Changing permission to rwxrwxrwx should work.

# chmod 777 /var/tmp

 >>shxxxx is variable , it changes with every new session.

I understand that, but if that file already exists in that directory and is owned by someone else, then a new user won't be able to create a new one.

[Steven Schweda]

> [oracle@healthynode][database]>ls -ld /var/tmp
> drwxrwxrwt 10 root root 8192 Nov 15 18:47 /var/tmp

> [oracle@recoverednode][oracle]>ls -ld /var/tmp
> drwxrwxr-t 8 root root 8192 Nov 15 19:22 /var/tmp

   To me, those permissions look different.  At least the owner:group
looks plausible.

> Changing permission to rwxrwxrwx should work.

   Perhaps, unless that "t" is actually significant.  I don't have an
HP-UX system up at the moment, so I know nothing, but my handy Mac also
has the "t":

pro3$ ls -ld /var/tmp
drwxrwxrwt 3 root wheel 102 Nov 14 22:02 /var/tmp

So, knowing nothing, I'd probably set the permissions to 1777 rather
than 777.

pro3$ mkdir fred
pro3$ ls -ld fred
drwxr-xr-x 2 sms staff 68 Nov 15 11:38 fred
pro3$ chmod 1777 fred
pro3$ ls -ld fred
drwxrwxrwt 2 sms staff 68 Nov 15 11:38 fred

[Dennis Handly]

>chown / chmod 777 was run by mistake on /usr. It was later fixed by going to single user.

Did you use the super dangerous chmod -R?  Fixed how?  Did you try "swverify -F"?

>[oracle@recoverednode][oracle]>ll -d /var/tmp
drwxrwxr-t 8 root root 8192 Nov 15 19:22 /var/tmp

The way to fix this is to use: chmod o+w /var/tmp

Don't ever be tempted to use use obsolete octal numbers, always use symbolic form.

># chmod 777 /var/tmp

This isn't the right fix, it removes the "t" (sticky) bit.  Now you have to use: chmod u+t /var/tmp

>if that file already exists in that directory and is owned by someone else, then a new user won't be able to create a new one.

I had that happen with rogue here docs, filled it up with tens of thousands of sh*.* files.

>unless that "t" is actually significant.

Only for security enforcement.

>pro3$ chmod 1777 fred

Or chmod a=rwx,u+t fred

[Torsten.]

IMHO the recovered system is not recovered and at risk. restoring ignite backup would be s safe option.

[Steven Schweda]

> Don't ever be tempted to use use obsolete octal numbers, always use
> symbolic form.

   Because ...?

> IMHO the recovered system is not recovered and at risk.

   Clearly, some damage remains.

>  restoring ignite backup would be [a] safe option.

   Comparing the affected files with equivalent files on an undamaged
system should help.  "swverify -F" should help.  "swverify" can't fix
non-OS files (about which it knows nothing), comparison works only for
common files, and backup works only for files older than the backup.
All of which serves as a reminder of why it pays to give the "root"
password to only those who have some idea of how much they don't know.

      https://en.wikipedia.org/wiki/There_are_known_knowns

[Dennis Handly]

>Because ?

Because of problems like this.  I.e. using "chmod 777 -R".  If you used "chmod a+w -R", you would only have security problems.