This looks like a duplicate of:
Bug #186294

Yes I saw bug 186294, but it deals with yum shell, and this one with smart. 

Fixed in selinux-policy-2.2.25-2.fc5

Hm, with selinux-policy-targeted-2.2.25-3.fc5:

Apr  3 23:53:11 viper kernel: audit(1144097591.971:6): avc:  denied  { read
write } for  pid=3787 comm="useradd" name="tmpn8cd2r-smart-rpm-out.txt" dev=sda3
ino=9647919 scontext=user_u:system_r:useradd_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Apr  3 23:53:12 viper kernel: audit(1144097592.167:7): avc:  denied  { read
write } for  pid=3787 comm="useradd" name="lastlog" dev=sda3 ino=12918469
scontext=user_u:system_r:useradd_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file


Anyway, the user is apparently created despite of the above noise, even in
Enforcing mode.  But something's not quite right, right?

Still happens with 2.2.29-3.fc5, and add restorecon from %post scripts to the list:

Apr 16 12:17:31 viper kernel: audit(1145179051.978:9): avc:  denied  { read
write } for  pid=27202 comm="restorecon" name="tmpxltSaE-smart-rpm-out.txt"
dev=sda3 ino=9647882 scontext=user_u:system_r:restorecon_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file

This looks like smart package manager is leaking a open descriptor to
name="tmpxltSaE-smart-rpm-out.txt", Also lastlog is labeled incorrectly.
Or it is somehow doing the equivalent of  restorecon > tmpxltSaE-smart-rpm-out.txt
restorecon /var/log/lastlog

Regarding the ....-smart-rpm-out.txt messages, looks like this happens when
smart is trying to internally capture stdout and stderr output from %post and
friends scriptlet commands using a tempfile.  I looked at the code and it
confused me a bit, but I couldn't find an obvious leak in it in a quick look.

The code is here:
http://svn.smartpm.python-hosting.com/trunk/smart/backends/rpm/pm.py
See grabOutput() in the RPMCallback class and the invocations a couple of lines
above the class definition.

Re: lastlog, I had it already relabeled ok afterwards, no more those messages.

Bumping to FC6, I'm still seeing these messages (SELinux in permissive mode).

@Axel: FYI

Oh, and it's not only useradd/groupadd; semodule, load_policy, setfiles,
genhomedircon, and restorecon seem affected too:

# grep smart-rpm-out.txt /var/log/messages.1
Dec 21 20:23:19 viper kernel: audit(1166725399.837:32): avc:  denied  { read
write } for  pid=17851 comm="semodule" name="tmpftBRrA-smart-rpm-out.txt"
dev=sda3 ino=7260297 scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Dec 21 20:23:25 viper kernel: audit(1166725405.675:33): avc:  denied  { read
write } for  pid=17856 comm="load_policy" name="tmpftBRrA-smart-rpm-out.txt"
dev=sda3 ino=7260297 scontext=user_u:system_r:load_policy_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Dec 21 20:23:26 viper kernel: audit(1166725406.002:35): avc:  denied  { read
write } for  pid=17857 comm="setfiles" name="tmpftBRrA-smart-rpm-out.txt"
dev=sda3 ino=7260297 scontext=user_u:system_r:setfiles_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Dec 21 20:23:26 viper kernel: audit(1166725406.291:36): avc:  denied  { getattr
} for  pid=17858 comm="genhomedircon" name="tmpftBRrA-smart-rpm-out.txt"
dev=sda3 ino=7260297 scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Dec 21 20:23:26 viper kernel: audit(1166725406.510:37): avc:  denied  { ioctl }
for  pid=17858 comm="genhomedircon" name="tmpftBRrA-smart-rpm-out.txt" dev=sda3
ino=7260297 scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file
Dec 21 20:23:27 viper kernel: audit(1166725407.247:38): avc:  denied  { read
write } for  pid=17888 comm="restorecon" name="tmpftBRrA-smart-rpm-out.txt"
dev=sda3 ino=7260297 scontext=user_u:system_r:restorecon_t:s0
tcontext=user_u:object_r:rpm_tmp_t:s0 tclass=file

# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.4.6-13.fc6.noarch

Should I do some selinux magic in the smart package? E.g. setting the context to
whatever yum and rpm have? If someone (Daniel?) gives me a hint on how to do
that outside of selinux-policy packages, I'll gladly add it.

What is happening here is that the smart package is reassiging the stdin and
stdout of all daemons to tmpftBRrA-smart-rpm-out.txt  Which is labeled by
default rpm_tmp_t.  When a confined domain starts up it checks whether it has
the expected access to all open file descriptors.  Ordinarilyt this is a
terminal and we have rules that say something like

dontaudit setfiles_t tty_device_t:chr_file rw_file_perms;

But since you are handing it an open file descriptor to rpm_tmp_t, it is
generating AVC messages.  These denials probably do not cause any problems, as
the the kernel just closes the file descriptor and reopens it pointed at /dev/null.

But the AVC's are a pain.  One hack that we have used in the past to get around
this problem is to pipe the output to cat and then have cat output to the file.

So instead of 

genhomedircon > /tmp/out

use

genhomedircon | cat > /tmp/out

This might work.

In our qa lab we actually update the policy during a test run with something like

policy_module(test, 1.0);

require {
      attribute domain;
}

allow domain rpm_tmp_t:file rw_file_perms;

Added dontaudit to selinux-policy-2.4.6-38

Fixed in current release