From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: SELinux <SELinux@tycho.nsa.gov>,
James Morris <jmorris@redhat.com>,
Russell Coker <russell@coker.com.au>
Subject: Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t
Date: Thu, 24 Mar 2005 15:06:08 -0500 [thread overview]
Message-ID: <42431DB0.7040803@redhat.com> (raw)
In-Reply-To: <1111685458.13486.61.camel@moss-spartans.epoch.ncsc.mil>
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Stephen Smalley wrote:
>On Thu, 2005-03-24 at 09:37 -0500, Stephen Smalley wrote:
>
>
>>For /tmp, a fscontext= mount seems to have an issue in that it is still
>>using type transitions for labeling inodes (including the root), so we
>>end up with mount_tmp_t on /tmp at least under strict policy. Possibly
>>we could/should change the way that works for the root inode.
>>
>>
>
>Possible workaround - mount with fscontext=, then run restorecon /tmp
>(not recursively, just on the top-level directory) from rc.sysinit.
>That would get us tmp_t on the superblock and tmp_t on the root
>directory. Then you just need a few policy modifications like allow
>tmpfile_t tmp_t:filesystem associate;, and you still can perform
>[gs]etfilecon and setfscreatecon on the filesystem.
>
>
>
I don't think we have do do any of that. It seems to work if you do a
restorecon /tmp
in the init scripts.
I am running strict policy with tmpfs mounted on /tmp
mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
none on /tmp type tmpfs (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
--
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 432 bytes --]
--- initscripts-8.05/rc.d/rc.sysinit~ 2005-03-24 15:02:51.000000000 -0500
+++ initscripts-8.05/rc.d/rc.sysinit 2005-03-24 15:03:11.000000000 -0500
@@ -593,6 +593,7 @@
fi
# Clean up various /tmp bits
+restorecon /tmp
rm -f /tmp/.X*-lock /tmp/.lock.* /tmp/.gdm_socket /tmp/.s.PGSQL.*
rm -rf /tmp/.X*-unix /tmp/.ICE-unix /tmp/.font-unix /tmp/hsperfdata_* \
/tmp/kde-* /tmp/ksocket-* /tmp/mc-* /tmp/mcop-* /tmp/orbit-* \
next prev parent reply other threads:[~2005-03-24 20:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 14:12 I would like to propose some kind of consolidation of tmpfs_t and tmp_t Daniel J Walsh
2005-03-24 14:37 ` Stephen Smalley
2005-03-24 14:44 ` Stephen Smalley
2005-03-24 17:30 ` Stephen Smalley
2005-03-24 20:06 ` Daniel J Walsh [this message]
2005-03-25 13:32 ` Stephen Smalley
2005-03-25 14:46 ` Daniel J Walsh
2005-03-24 22:11 ` Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42431DB0.7040803@redhat.com \
--to=dwalsh@redhat.com \
--cc=SELinux@tycho.nsa.gov \
--cc=jmorris@redhat.com \
--cc=russell@coker.com.au \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.