On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
> On November 6, 2012 at 4:06 PM mp.lists@xxxxxxx wrote:
> > Hi *,
> >
> > I think, measures can|should be taken, which reduce the probability of having
> > a
> > swap file inadvertently run with too open permissions.
well, you need root permissions to use swapon, the swap devices and
files are defined in /etc/fstan which is writable by root only.
I have doubts that we have to make the system so paranoid and
resistant to admin's bugs. And if you really need this level of
paranoia then use SELinux (or so) rather than expect hardcoded rules
in swapon(8).
> > As a first idea, it looks, as if such may be implemented, eg. by
> > letting swapon [and fstab-based "mounting"] by default not enable a swap
> > file, if it has non-root access permissions
>
> Did you know?
> The swapon utility issues a warning diagnostic with --verbose:
>
> # ls -l /tmp/swapfile
> -rw-r--r-- 1 berny users 134217728 Nov 6 17:03 /tmp/swapfile
>
> # sbin/swapon -v /tmp/swapfile
> swapon /tmp/swapfile
> swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
> swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
> swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same byte
> order
> swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728, devsize=134217728
this waring is there since year 1999.. so it's really nothing new.
> BTW: the check for the owner has been added in 2.19
> (in commit v2.18-88-g306c1df).
>
> I don't know if refusing to swapon insecure swap files is a good
> idea (see below).
>
> > || letting mkswap by default ignore too open settings of umask and create
> > the
> > swap file mod 0600 instead.
sorry, this is nonsense
> You don't need root privs to run mkswap. Furthermore, mkswap
> doesn't create the swap file (in terms of calling creat()).
yep, you can use cp(1) or dd(1) to create the file as a copy...
> Instead, it just writes to it.
> Nevertheless, I think a warning would be enough/nice at this stage.
>
> > In both cases, an explicit switch|parameter could enable the present,
> > non-restrictive behaviour.
>
> Changing behavior is not always a good idea for compatibility reasons,
> and therefore deserves *good* arguments.
Yes, I don't see good arguments.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
