how to make a file write-able but not modifiable through editor

[Muhammad Ahmad]

Hi,

Good Day!

i wanna make .sh_history secure, like the user can't modify this file by means of any text editor or through other ways like echo output redirection commands, the purpose behind the scene is to maintain the integrity of user's command history file.



Any idea?

-Br
-Muhammad Ahmad

[Jeeshan]

you can use chatr command to change the internal attribute

#man chatr

[Ivan Krastev]

chatr is for programs/libraries.

On Linux you can do it with chatr, but i don't know something similar under HP-UX.

regards,
ivan

[VK2COT]

Hello,

Did you try setacl (similar to setfacl for
Linux and Solaris)?

Cheers,

VK2COT

[Dennis Handly]

You can't do this. If the shell can write to the file so can the user.

If you want to monitor what users do, you'll have to use a different tool.

[Elmar P. Kolkman]

I guess there is a way: after the shell is started, move the history file to a directory that is not accessible by the user... Since the shell has the file already open, it will keep on writing, but the user cannot access the file.

I haven't tried, but it should work... It's like removing the syslog.log file without triggering the syslogd to re-create the file... It will keep on writing to the deleted file.

[Dennis Handly]

>Elmar: Since the shell has the file already open, it will keep on writing, but the user cannot access the file.

I'm not sure this will work if you create a new shell by invoking a script. It is going to want to use $HISTFILE, which isn't there.

[Elmar P. Kolkman]

No problem... It will just create a new one ;-)

[PW HP-UX Support Team]

You can always install the B1 version of Unix and all your file level security problems will go away !~)

[TTr]

The .sh_history (or whatever $HISTFILE is set to) is NOT a command security tool, it is just that a "command history" for the user. The shell that writes to it IS running as the same user so in order to move it to a nonaccissible area, you have to have an SUID script/command doit as part of the login profile. And this will only make a copy of it each time the user logs in and a new one will be started in the default location.
To complicate the scenario think on what would happen if a user logged in on several different concurrent or overlapping sessions.
In any case a smart user can purge or delete the history file during the shell and as they log out so there is nothing left to look at. Or they can unset the HISTFILE as soon as they login.
Bottom line is don't rely on the history file for investigative work on your users.
Look into trusted system and user accounting setups for user command tracking.