packages in TeXShop (was: Re: [OS X TeX] question regarding spacing after a period)

[cfrees at imapmail.org]

On Sat 14th Mar, 2009 at 14:58, Peter Dyballa seems to have written:

>
> Am 14.03.2009 um 01:04 schrieb cfrees at imapmail.org:
>
>> 	echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 | sed 
>> -e '/Permission denied/d'
>
>
> Clea,
>
> thank you for being so insistent!
>
> When I updated from Panther to Tiger Launch Service did not seem to perform 
> as documented (maybe I should have waited longer than a day of eight or ten 
> hours), so I let it coexist with anacron. Since I did not understand what the 
> cited line was doing, if it really performed the update since the shell 
> script is just an argument for echo, I created my own addition. And then I 
> saw the reports in the LOG files about root permissions, so I added the 
> /etc/locate.rc file with its PRUNEPATHS setting. The reports persisted, but I 
> could be sure that security was saved.
>
> This morning I experimented. I let the cited command (plus the ones to set 
> permissions for /var/db/locate.database) run in a shell owned by root. Once 
> *with* my /etc/locate.rc file, and a second time without it. The command 
> "apply 'locate /Users/%1/ | wc -l' Shared admin arobert btest ctest x11 pete" 
> revealed
>
> 	  with   /etc/locate.rc   without
> 	    2844                   2844
> 	    1333                   1343	(find ~admin | wc -l => 1353)
> 	      14                     14
> 	      35                     35
> 	      32                     32
> 	      77                     77
> 	  243121                 243137	(find ~ | wc -l => 310664, so some 
> files aren't locatable)
>
> 	  945225                 946892
>
> The latter number come from "locate '*' | wc -l" – locate can handle some 
> regular expressions. So the /usr/libexec/locate.updatedb shell script scans 
> all user's home directories – and leaves out /var/root, root's home directory 
> (locate /var/root/ | wc -l => 0). Without /etc/locate.rc the GnuPG 
> directories *are* scanned: "locate '/Users/*' | grep -i gnupg | wc -l" 
> reports a number greater than zero (OK, I could set permissions to 711 or 
> less)! And of course a DVD, which I exclude via PRUNEPATHS.

The default permissions for ~/.gnupg are 700 as far as I know. gpg will
warn about unsafe home directory permissions...

> So I have to do two things: update PRUNEPATHS and comment the cited line in 
> /etc/periodic/weekly/500.weekly. Executing the shell script 
> /usr/libexec/locate.updatedb as nobody or as root makes no difference – 
> except: nobody *will* stumble over directories or files it can't read – and 
> this could lead to side effects. My own scheme relies on 
> /usr/libexec/locate.updatedb working correctly, as run by any account.

I'm not sure I follow all this and it is late. Yes, the default command
in the weekly script will come across stuff it cannot read. It depends
on the fact that nobody (unlike root) cannot read the contents of
~/.gnupg etc. That's why the initial results include "permissions
denied" messages which are filtered out by sed as the database is
built.

Your test will return a non-zero result I think because the entry for,
say, "/Users/yourname/.gnupg" will be entered into the database because
"/Users/yourname" is readable by everyone. But if you grepped for, say,
pubring.gpg, you should get zero results because the permissions on
your .gnupg directory do not (or should not) permit others to list the
contents of the directory.

On my system (which is using the standard command for updating the
database as given above), "locate .gnupg" gives 2 results:
~/.resources/.gnupg and ~/.resources/.gnupg.bkup. (The use of
.resources is non-standard, I think. Default would be just ~/.gnupg.)
But "locate pubring.gpg" returns nothing whatsoever because the
standard permissions for .gnupg are 700.

Essentially, locate will only show what any user on the system can see
directly without locate. (That is, ls /Users/me/.resources will work
including .gnupg but ls /Users/me/.resources/.gnupg will fail for any
user other than me or root.)

Because I sometimes want to find files in my private directories, I
use glocate with separate databases. glocate uses a standard database
for non-private stuff (similar to what is in the locate database) but
it also uses a database in my home directory which was created as me.
This will list pubring.gpg etc. but the second, user-specific database
is only readable by me anyway so, again, nobody else can get private
results. glocate is a bash-function:
/usr/local/bin/glocate -d /usr/local/var/locatedb:${HOME}/Library/Indexes/locatedb.${USER} "$@"
where /usr/local/bin/glocate is GNU locate.
Any other user, however, will have glocate as /usr/local/bin/glocate
unless a similar function has been defined for that user. If the user
defines a similar function, of course, glocate will look for that
user's personal database. Because other users cannot read
/Users/me/Library/.../locatedb.me, it isn't possible for other users to
use the private database. So glocate let's me get all the results I
want without revealing them to other users.

> In *any* case /usr/libexec/locate.updatedb does *not* search *some* sub-trees 
> in a user's home directory. A rule cannot be deduced, at least not by me ... 
> (Maybe I should also, or better, check the original GNU locate utilities!)

The important point about the default command in the weekly script is
*who* runs /usr/libexec/locate.updatedb. If it was run as root, that
would definitely be problematic. Fortunately, it runs as a
non-privileged user.

If you look at GNU be warned: the version of locate I have from Apple and
the version of GNU locate I have use incompatible database formats.
This can produce  rather confusing errors (at least, they confused me)
if you're not aware of it.

- cfr

> --
> Greetings
>
> Pete
>
> Hard Disk, n.:
> 	A device that allows users to delete vast quantities
> 	of data with simple mnemonic commands.
>
>
>
>