Control: severity -1 minor
On 30/12/12 19:07, Roger Leigh wrote:
> Does /dev/shm exist on a standard kFreeBSD install?
It gets created by initscripts as symlink to /run/shm. Otherwise it
would not be there; apparently Linux 2.6 invented it and it didn't seem
too popular with upstream FreeBSD.
> It's a glibc requirement.
I didn't know this. Software running in the jails fortunately seems to
be using /run/shm properly.
Within jails, I cannot write to /dev (even as root) so shm cannot be
created as a directory or symlink. But as an alternative I can create
it from the host system before booting, so that will do as a workaround
and for compatibility.
Jails, and how to use them, are still a bit experimental/undocumented
for GNU/kFreeBSD. Thanks for your input on this; I'll make sure this
gets written up somewhere.
>> + ls -A /run/shm
>> + [ .tmpfs != ]
>>
>> This command indicates there is a file in this folder, called .tmpfs
>> (though it isn't really a tmpfs), and so:
>
> Why does this file exist here?
It's timestamped from when the jailed system booted, which would have
been with initscripts 2.88dsf-32.
It seems to be created by mount_shm in mount-functions.sh. Is it
missing from the cleanup here in bootmisc?
# Remove bootclean's flag files.
# Don't run bootclean again after this!
rm -f /tmp/.clean /lib/init/rw/.clean /run/.clean /run/lock/.clean
rm -f /tmp/.tmpfs /lib/init/rw/.tmpfs /run/.tmpfs /run/lock/.tmpfs
While here - could neaten this up a little:
for dir in /lib/init/rw /tmp /run /run/lock /run/shm; do
rm -f "$dir/.clean" "$dir/.tmpfs"
done
>> On the other hand, if there'd been some non-hidden files/directories
>> there, they would be moved, but any remaining hidden ones would be
>> deleted(!).
>
> For the use case in question (in chroots) this is by design.
> There is no use case for dotfiles in /dev/shm.
In that case, the "ls -A" flag is unnecessary? A plain "ls" would
determine if anything in that directory needs keeping. And the error
with "mv" would be avoided.
> This is certainly safer. However, we should be catering for this
> already--we shouldn't be doing any modification of /dev if it's
> a mountpoint of any sort.
I'm not sure exactly what you mean by modification, but at least for the
mmdd|mddd cases it will try to move files to /dev/shm
Maybe it's not a realistic situation, but since there is no trailing
slash, if /dev/shm didn't exist, a malicious user could have created in
advance:
1. a symlink /run/shm/oops -> /etc (which gets placed first as /dev/shm)
2. regular file /run/shm/passwd (which gets written over /etc/passwd)
> Currently we are making
> the assumption that it will be present, and I'm not sure if that's
> a bug or not.
I'm not sure either. The above issue poses a security risk, so I'd
consider adding a trailing slash (so that "mv" fails with an error
instead); I guess it is unlikely though and so needn't be fixed with
any urgency.
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50e0a43f.7000...@pyro.eu.org
