Very Computer

I installed Red Hat 7.1 last week, it was working okay.  I downlaoded
'nmap-2.54BEA7-3.i386.rpm', 'rpm -i'  and  played port scanning my home
network, ISP, work while still login as root.  Then I login as non-root,
now sez:

bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied

I login back as root and 'chmod 777 /dev/null'.   Why saying "bash:
/dev/null: Permission denied"  when it wasn't doing that before?

Why is unclear to me, but the normal mode is
        ~$ ls -l /dev/null
        crw-rw-rw-    1 root     devices    1,   3 Apr 22 14:20 /dev/null

--
  SwifT
  |- LUG : http://www.lugwv.be
  |- PGP Key-# : 0xCDBA2FDB
  `- "Happy GNU/Linux-user :)"

On Mon, 20 Aug 2001 09:03:14 GMT,

The question is rather, what program did modify the permission of /dev/null?
That program should probably be fixed so it no longer does that.

Villy

On 20 Aug 2001 11:45:29 GMT, Villy Kruse

If it is a program that did this (nmap from what I understand - although I
don't have any troubles with nmap) and not a careless user logged in as root
(no offence).

OP: look at the root's .bash_history and see what tools you have ran. Test
each tool to see if that was the one that did it.

--
  SwifT
  |- LUG : http://www.lugwv.be
  |- PGP Key-# : 0xCDBA2FDB
  `- "Happy Linux-user :)"

When I ran 'chmod 777 /dev/null' it should show crwxrwxrwx but not anymore.

I downloaded linuxconf-1.24r2-10.i386.rpm when 'rpm -i linuxconf*' it
prompted to fix or do nothing to the /dev/null.  I selected 'fix it' so
permission so now seems normal again...

Script started on Mon Aug 20 19:31:18 2001
$  ls -l /dev/null
crw-rw-rw-    1 root     root       1,   3 Mar 23 20:37   /dev/null
~ $ exit
Script done on Mon Aug 20 19:31:26 2001

Still I don't have clue why I got that that '/dev/null: Permission denied' in
the first place.

Thanks.

On Mon, 20 Aug 2001 19:27:40 GMT,

Could be an output file you have specified as a real file, but the OP has
specified as /dev/null.  If the program has the idea that this file should
be root accessible only then it might chmod the output file.  Cases like
this is not unheard of.

The careless part might be a recursive chown gone wild, but then I would
suspect much more damage done in the /dev directory.

Villy

I'd have to see the line that you typed when you got the error message.
For instance:

  echo Hello > /dev/null   # works fine

but:

  echo Hello | /dev/null   # gives "/dev/null: Permission denied"

Not that you couldn't write to it, but you can't execute it.

--
Dave Brown  Austin, TX

I was the one made the original posting and lookie what I found.  I was reading
through a book Red Hat? Linux? 7 Server by Mohammed J. Kabir ISBN 0-7645-4786-0 at
Barnes & Noble and I ended up buying it.  I think it's a good reference...

In chapter 4:  Understanding UNIX files and Devices says, if something that was
working yesterday and day before yesterday all of a sudden stops working today,
the first suspect is permission problem.  One of the most common causes of
permission problem is that after using Mr. Superuser 'root' account.   Many of
inexperienced superusers like me often access files and run programs using Mr.
Superuser 'root' account.  When a program is run using 'root 'as user account, the
files that such program creates can often be set with root ownership.  Mr. Nobody
user logins and he can't access the file because Mr. Superuser 'root' already owns
it.

I've been using UNIX for almost 10 years as non root I didn't even know that.

I was the one made the original posting and lookie what I found.  I was reading
through a book Red Hat? Linux? 7 Server by Mohammed J. Kabir ISBN 0-7645-4786-0 at
Barnes & Noble and I ended up buying it.  I think it's a good reference...

In chapter 4:  Understanding UNIX files and Devices says, if something that was
working yesterday and day before yesterday all of a sudden stops working today, the
first suspect is permission problem.  One of the most common causes of permission
problem is that after using Mr. Superuser 'root' account.   Many of inexperienced
superusers like me often access files and run programs using Mr. Superuser 'root'
account.  When a program is run using 'root 'as user account, the files that such
program creates can often be set with root ownership.  Mr. Nobody user logins and
he can't access the file because Mr. Superuser 'root' already owns it.

I've been using UNIX for almost 10 years as non root I didn't even know that.