All of lore.kernel.org
 help / color / mirror / Atom feed
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-*  \

  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.