writable protected file

Greetings

I am trying to create a solution that will log information into a file. That is the easy part.

What I am trying to do is have a front end script that ill ask a user what their reasoning is for logging in and log that reason into a file. The hard part I am finding is that I need that file to be such that the user can not modify it.

My first thought is that if the file can be written to then it can be modified but I wanted to ask here to see if this is possible.

Not sure I understand.

What do you mean by reason should be logged but user should not be able to modify that ?

One thing that I could think of is,
run the logging script as a different user - then its done

When a user logs in, there is a script that is run which prompts for a reason that they are logging in. That reason should then be logged in a file that is "protected". So that it can not be modified.

More:
How will the front end script be called?
If the user can find out and look at it, he will know the name of the logfile... and yes if you can write to it you can modify it...

The script is called via exec with traps from the user's .profile.

You could simply use the "logger" command with an appropriate priority in the script and use syslog to handle the logging part. That should resolve the issue you are having.

hmmmm good lead, however it will only log to the syslog. Would be perfect if I could specify a file to write the message to.

You could try to customize /etc/syslog.conf:
This is what I have on my favorite box:

mail.debug                      /var/adm/syslog/mail.log
*.info;mail,auth,local5.none    /var/adm/syslog/syslog.log
local5.notice                   /var/adm/syslog/syslog.log
local5.info                     /var/adm/syslog/ftp.log
auth.info                       /var/adm/syslog/auth.log
*.alert                 /dev/console
*.alert                 root
*.emerg                 *
#*.err                  /var/adm/syslog/err.log

The user can edit the profile unless you have it owned by another user maybe root. Watch permissions.

traps are in place so that breaking out of the script logs them out of the system.

Why not just use a restricted shell, or even better chroot those users. You obviously are trying to enforce a security paradigm.