Angband 3.1.1 save dir
camlost
I've just experienced some minor issues when compiling angband from
sources on Ubuntu 9.10.
After generating the DEB package (using checkinstall), save files have
been stored in /usr/local/share/angband/save.
How to make angband save files to ~.angband/* ?
(Not mentioning the /usr/local/share/angband/save directory hasn't
allowed ordinary users to write files.)
Thanks
c.
Matthew Vernon
> Hi there,
> I've just experienced some minor issues when compiling angband from
> sources on Ubuntu 9.10.
> After generating the DEB package (using checkinstall), save files have
> been stored in /usr/local/share/angband/save.
That's usual. Typically you make the angband executible setgid games;
this means angband can write save-files, but normal users cannot
tamper with them.
> How to make angband save files to ~.angband/* ?
You don't want to do that, because that would enable save-scumming.
HTH,
Matthew
--
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org
The Wanderer
> camlost <jiri....@gmail.com> writes:
>
>> Hi there,
>> I've just experienced some minor issues when compiling angband from
>> sources on Ubuntu 9.10.
>> After generating the DEB package (using checkinstall), save files
>> have been stored in /usr/local/share/angband/save.
>
> That's usual. Typically you make the angband executible setgid games;
> this means angband can write save-files, but normal users cannot
> tamper with them.
>
>> How to make angband save files to ~.angband/* ?
>
> You don't want to do that, because that would enable save-scumming.
For one thing, if (he?) wants to allow save-scumming, that's his
prerogative.
For another thing, just because having save files under ~/.angband/
would allow save scumming doesn't mean that non-save-scumming people
might not want to do it. (For that matter, with root access even global
save files could be save-scummed with only a little extra work; given
how commonly sudo is used these days, I'm not sure trying to avoid
save-scumming by denying file access is even effective much less worth
the while.)
Personally, I install Angband with a prefix of ~/angband/(someversion)/,
so that the entire Angband hierarchy gets stored in my home directory.
That wouldn't work for a "global install" setup, but since I'm the only
one who uses my machine to play Angband, it works quite well for my
purposes.
I do think that there should be a way to have Angband installed globally
(/usr/local/bin/angband, or similar) but set to use a per-user save-file
location. Not everyone would want that, but those who do should be
allowed to have it.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Magnate
> On 12/07/2009 10:32 AM, Matthew Vernon wrote:
>> camlost <jiri....@gmail.com> writes:
>>
>>> Hi there,
>>> I've just experienced some minor issues when compiling angband from
>>> sources on Ubuntu 9.10.
>>> After generating the DEB package (using checkinstall), save files
>>> have been stored in /usr/local/share/angband/save.
>>
>> That's usual. Typically you make the angband executible setgid games;
>> this means angband can write save-files, but normal users cannot
>> tamper with them.
./configure --with-setgid=games
>>> How to make angband save files to ~.angband/* ?
./configure --with-private-dirs
(This is now the default if you just invoke ./configure with no arguments.)
>> You don't want to do that, because that would enable save-scumming.
>
> For one thing, if (he?) wants to allow save-scumming, that's his
> prerogative.
>
> For another thing, just because having save files under ~/.angband/
> would allow save scumming doesn't mean that non-save-scumming people
> might not want to do it. (For that matter, with root access even global
> save files could be save-scummed with only a little extra work; given
> how commonly sudo is used these days, I'm not sure trying to avoid
> save-scumming by denying file access is even effective much less worth
> the while.)
>
> Personally, I install Angband with a prefix of ~/angband/(someversion)/,
> so that the entire Angband hierarchy gets stored in my home directory.
> That wouldn't work for a "global install" setup, but since I'm the only
> one who uses my machine to play Angband, it works quite well for my
> purposes.
>
> I do think that there should be a way to have Angband installed globally
> (/usr/local/bin/angband, or similar) but set to use a per-user save-file
> location. Not everyone would want that, but those who do should be
> allowed to have it.
Yep, it exists. As of 3.1.2dev there are three main build options:
--with-setgid=foo
This places the executable in $execprefix/, which defaults to
/usr/local/bin, and sets it to setgid foo. The other files go in
$prefix/etc/angband (the edit/ and file/ directories),
$prefix/var/games/angband (the apex/ and save/ dirs) and
$prefix/share/angband (the rest). $prefix defaults to /usr/local. You can
further specify the three destinations with $configdir, $vardir and $libdir
respectively. In addition, on POSIX systems, the lib/user directory is
always set to ~/.angband/Angband
--with-private-dirs
Same as above except that the executable is not setgid, and $vardir is set
to ~/.angband/Angband/, in which the subdirs save/ and scores/ (not apex/)
are created.
--with-no-install
All files are left where they were extracted from source, ie. in lib/
(including lib/user). The built executable is copied to ..
I'm hoping this pretty much caters for all requirements (on *nix systems) -
please let me know if not.
CC
Ray
>> On 12/07/2009 10:32 AM, Matthew Vernon wrote:
>>> camlost <jiri....@gmail.com> writes:
>>>
>>>> Hi there,
>>>> I've just experienced some minor issues when compiling angband from
>>>> sources on Ubuntu 9.10.
>>>> After generating the DEB package (using checkinstall), save files
>>>> have been stored in /usr/local/share/angband/save.
>>>
>>> That's usual. Typically you make the angband executible setgid games;
>>> this means angband can write save-files, but normal users cannot
>>> tamper with them.
It's also wrong. /usr is for constant data, not changing data. If
you want a per-user installation then put it in the user's home
directory; but for a setgid installation, it belongs in /var, not
/usr.
According to the FHS, (http://www.pathname.com/fhs/) the /usr directory
is for readonly files - ie, files not expected to change as a result
of someone just using a particular application. This is fairly
important when securing a system because you can put /usr on a
different partition and mount that partition readonly, preventing a
class of attacks that involves modifying, eg, programs or program
data stored there.
I think you could store the executable and edit files under /usr,
as you suggest; recompiling or changing the 'edit' files is a
configuration task, not something that players do. But savefiles
and high scores change as a result of players playing the game; if
a system is secured (and /usr is readonly, as it should be on any
server) this will not work.
Shared files (or shared directories) that change as a result of playing
the game would belong somewhere under /var. This definitely includes
the highscores file. This includes the savefiles directory if you want
to make them SetGID-owned and put them in a SetGID-owned directory
where nonroot local players can't read/write them in order to savescum.
Bear
Magnate
news:4b20086f$0$1651$742e...@news.sonic.net...
>>> On 12/07/2009 10:32 AM, Matthew Vernon wrote:
>>>> camlost <jiri....@gmail.com> writes:
>>>>
>>>>> Hi there,
>>>>> I've just experienced some minor issues when compiling angband from
>>>>> sources on Ubuntu 9.10.
>>>>> After generating the DEB package (using checkinstall), save files
>>>>> have been stored in /usr/local/share/angband/save.
>>>>
>>>> That's usual. Typically you make the angband executible setgid games;
>>>> this means angband can write save-files, but normal users cannot
>>>> tamper with them.
>
> It's also wrong. /usr is for constant data, not changing data. If
> you want a per-user installation then put it in the user's home
> directory; but for a setgid installation, it belongs in /var, not
> /usr.
>
> According to the FHS, (http://www.pathname.com/fhs/) the /usr directory
> is for readonly files - ie, files not expected to change as a result
> of someone just using a particular application. This is fairly
> important when securing a system because you can put /usr on a
> different partition and mount that partition readonly, preventing a
> class of attacks that involves modifying, eg, programs or program
> data stored there.
Agreed. The angband build system is now FHS-compliant - nothing writable
goes in /usr..
> I think you could store the executable and edit files under /usr,
> as you suggest; recompiling or changing the 'edit' files is a
> configuration task, not something that players do. But savefiles
> and high scores change as a result of players playing the game; if
> a system is secured (and /usr is readonly, as it should be on any
> server) this will not work.
Actually edit files go in /etc/angband, which is FHS-compliant.
> Shared files (or shared directories) that change as a result of playing
> the game would belong somewhere under /var. This definitely includes
> the highscores file. This includes the savefiles directory if you want
> to make them SetGID-owned and put them in a SetGID-owned directory
> where nonroot local players can't read/write them in order to savescum.
Shared score and save directories go under /var if the setgid build method
is used (i.e. for a system-wide install with system-wide score file).
If --with-private-dirs is used, nothing goes in var, and all dynamic data
(scores, dumps, saves, prefs) are in ~/.angband/Angband.
HTH,
CC