Stephen Smalley (sds@xxxxxxxxxxxxx) said:
> > OK, once doing this, I get:
> >
> > avc: denied { search } for pid=1688 comm="mount" name="/" dev=tmpfs ino=5444
> > scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:fs_t:s0
> > tclass=dir
>
> Ah, yes. tmpfs / fs_use_trans is a bit different; inodes are labeled
> based on transition SID computed from allocating task SID and superblock
> SID.
>
> > And, then, expectedly, after fixing that, restorecon can't getattr/read/etc
> > fs_t.
> >
> > I seem to be stuck in a neverending cascade of AVCs. What's generally
> > wrong here?
> >
> > The usage model is this:
> >
> > 1) mount a tmpfs under /var somewhere
> > 2) take a predefined list of dirs and files, and for each one:
> > a) copy it to that tmpfs
> > b) bind mount it over its original location
> > c) restrorecon @ the original location, to get the contexts right
> >
> > This shouldn't be *that* hard to get working with policy, should it?
>
> This is beginning to make me think that fs_use_trans behavior isn't
> quite what it needs to be, or that we need an alternate (new) behavior
> for tmpfs. tmpfs has always been a bit of a sore spot because of its
> multiple uses for the kernel-internal shm mount, the userspace POSIX shm
> mount, and any other arbitrary use.
>
> Possibly stupid question: Will files be created dynamically in these
> tmpfs mounts at runtime?
Yes. Consider pid files in /var/run, lock files in /var/lock, etc.
> Do you expect them to follow the traditional
> inherit-from-parent-directory behavior you get from ext3?
Yes.
Bill
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
