Re: unwritable PKG_CACHE directory

2015-07-14 Thread Dale Lindskog
If your point is that this is too trivial to waste more time on, then 
c'est la vie.  But just in case you also think you are right:

 It's simple. PKG_CACHE is a parameter to pkg_add.  If you run other 
 options, like -n or -s, there is an obvious interface conflict. What 
 should pkg_add obey ?
 
 ...  If PKG_CACHE is defined, pkg_add will obey it.

pkg_add doesn't always obey it:

# ls -ld $PKG_CACHE/gcal*
ls: /var/pkg_cache/gcal*: No such file or directory
# pkg_add -s gcal
quirks-2.54 signed on 2015-03-08T12:33:05Z
# ls -ld $PKG_CACHE/gcal*
ls: /var/pkg_cache/gcal*: No such file or directory



Re: unwritable PKG_CACHE directory

2015-07-13 Thread lists
 I object to the silent part... if you're trying to actually use PKG_CACHE
 then, having it fail silently and then discovering several GB later that oops,
 it didn't save anything anywhere looks like a huge mistake.
 
 But I'll try to make the error message be completely explicit.

http://marc.info/?l=openbsd-cvsm=143671276012679

Thank you, Marc.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm.diff?r1=1.113r2=1.114



Re: unwritable PKG_CACHE directory

2015-07-13 Thread Dale Lindskog
Sorry!  My email was garbled: a combination of a failure to refresh the 
screen and no morning coffee.  Here it is again:

I disagree that pkg_add should always error out when PKG_CACHE is 
unwritable.  Specifically, when pkg_add is invoked with the -s option, no 
package is copied to the package cache even if it is writable.

Unless you think that pkg_add should always be run by root?  -- Dale



Re: unwritable PKG_CACHE directory

2015-07-13 Thread Dale Lindskog
On Mon, 13 Jul 2015, li...@wrant.com wrote:

  I object to the silent part... if you're trying to actually use PKG_CACHE
  then, having it fail silently and then discovering several GB later that 
  oops,
  it didn't save anything anywhere looks like a huge mistake.
  
  But I'll try to make the error message be completely explicit.
 
 http://marc.info/?l=openbsd-cvsm=143671276012679
 
 Thank you, Marc.
 
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm.diff?r1=1.113r2=1.114
 

Thanks Marc, t I disagree that pkg_add should always error outwhen 
PKG_CACHE is unwritable.  Specifically, when pkg_add is invoked the -s 
option, no package is copied to the package cache even if it is writable.

Unless you think that pkg_add should always be run by root?  -- Dale



Re: unwritable PKG_CACHE directory

2015-07-13 Thread Marc Espie
On Mon, Jul 13, 2015 at 12:21:07PM -0600, Dale Lindskog wrote:
 On Mon, 13 Jul 2015, li...@wrant.com wrote:
 
   I object to the silent part... if you're trying to actually use 
   PKG_CACHE
   then, having it fail silently and then discovering several GB later that 
   oops,
   it didn't save anything anywhere looks like a huge mistake.
   
   But I'll try to make the error message be completely explicit.
  
  http://marc.info/?l=openbsd-cvsm=143671276012679
  
  Thank you, Marc.
  
  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm.diff?r1=1.113r2=1.114
  
 
 Thanks Marc, t I disagree that pkg_add should always error outwhen 
 PKG_CACHE is unwritable.  Specifically, when pkg_add is invoked the -s 
 option, no package is copied to the package cache even if it is writable.
 
 Unless you think that pkg_add should always be run by root?  -- Dale

For fuck's sake, undefining PKG_CACHE if you want to run things as non-root
is easy enough. Stop talking crap.

It's simple. PKG_CACHE is a parameter to pkg_add.   If you run other options,
like -n or -s, there is an obvious interface conflict. What should pkg_add
obey ?

I will err on the side of KEEPING THINGS SIMPLE. If PKG_CACHE is defined,
pkg_add will obey it. Don't want PKG_CACHE ? unset it while running pkg_add
with those options. That way, I don't have to put more tests in there.



Re: unwritable PKG_CACHE directory

2015-07-07 Thread Craig Skinner
On 2015-07-06 Mon 23:08 PM |, Chris Bennett wrote:
 If you want to have a writable PKG_CACHE, why not do something simple
 like /home/dude/pkg_cache?
 

$ printenv PKG_CACHE
/var/cache/pkgs

$ ls -lod /var/cache /var/cache/pkgs
drwxr-xr-x  8 root  wheel  nodump  512 May 28 21:57 /var/cache/
drwxrwxr-x  2 root  wheel  -  8704 Jul  6 07:39 /var/cache/pkgs/

Those in wheel group can pkg_add -n, caching for later root install.



Re: unwritable PKG_CACHE directory

2015-07-07 Thread Marc Espie
On Mon, Jul 06, 2015 at 07:15:06PM -0600, Dale Lindskog wrote:
 It is discouraged but possible to run pkg_add(1) with -n or -s as a user 
 other than root.  However, if pkg_add(1) does not have write permission to 
 $PKG_CACHE, then unclear error messages are produced.  For example:
 
 $ ls -ld $PKG_CACHE
 drwxr-xr-x  2 root  wheel  3072 Jul  2 12:13 /var/pkg_cache
 $ pkg_add -vn gcal
 pkg_add should be run as root
 Update candidates: quirks-2.54 - quirks-2.54
 quirks-2.54 signed on 2015-03-08T12:33:05Z
 Fatal error: Ustar 
 [ftp://ftp.openbsd.org/pub/OpenBSD/5.7/packages/amd64/gcal-3.6.3p0.tgz][?]: 
 Error while reading header
  at /usr/libdata/perl5/OpenBSD/Ustar.pm line 89.
 
 One solution is for pkg_add(1) to silently omit the attempt to copy the 
 package to an unwritable $PKG_CACHE.  Below is a diff that achieves this, 
 and modifies pkg_add(1)'s man page accordingly.
 
 Index: pkg_add.1
 ===
 RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
 retrieving revision 1.132
 diff -u -p -r1.132 pkg_add.1
 --- pkg_add.1 16 Apr 2015 20:01:39 -  1.132
 +++ pkg_add.1 7 Jul 2015 00:51:22 -
 @@ -371,7 +371,7 @@ Don't actually install a package, just r
  would be taken if it was.
  Will still copy packages to
  .Ev PKG_CACHE
 -if applicable.
 +if applicable, and if pkg_add has write permission to that directory.
  .It Fl P Ar type
  Check permissions for distribution, where
  .Ar type
 Index: OpenBSD/PackageRepository.pm
 ===
 RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
 retrieving revision 1.113
 diff -u -p -r1.113 PackageRepository.pm
 --- OpenBSD/PackageRepository.pm  4 Mar 2015 13:55:32 -   1.113
 +++ OpenBSD/PackageRepository.pm  7 Jul 2015 00:51:22 -
 @@ -534,7 +534,7 @@ sub open_pipe
   $object-{pid2} = $pid2;
   } else {
   open STDERR, '', $object-{errors};
 - if (defined $object-{cache_dir}) {
 + if (defined $object-{cache_dir} and -w $object-{cache_dir}) {
   my $pid3 = open(my $in, -|);
   $self-did_it_fork($pid3);
   if ($pid3) {
I object to the silent part... if you're trying to actually use PKG_CACHE
then, having it fail silently and then discovering several GB later that oops,
it didn't save anything anywhere looks like a huge mistake.

But I'll try to make the error message be completely explicit.



Re: unwritable PKG_CACHE directory

2015-07-07 Thread Chris Bennett
On Mon, Jul 06, 2015 at 10:15:20PM -0600, Dale Lindskog wrote:
 On Mon, 6 Jul 2015, Chris Bennett wrote:
 
  If you don't have root access, should you really be installing packages?
 
 It is impossible to install packages when you are not root.  pkg_add won't 
 let you.
 
 This isn't about installing packages without root access.  This is about 
 the -n and -s options, which I often run as a non-root user.  The -n and 
 -s options don't actually install packages.

OK, now I see what you are doing and asking for.
Makes sense and seems useful. Sorry for the noise.

Chris Bennett



unwritable PKG_CACHE directory

2015-07-06 Thread Dale Lindskog
It is discouraged but possible to run pkg_add(1) with -n or -s as a user 
other than root.  However, if pkg_add(1) does not have write permission to 
$PKG_CACHE, then unclear error messages are produced.  For example:

$ ls -ld $PKG_CACHE
drwxr-xr-x  2 root  wheel  3072 Jul  2 12:13 /var/pkg_cache
$ pkg_add -vn gcal
pkg_add should be run as root
Update candidates: quirks-2.54 - quirks-2.54
quirks-2.54 signed on 2015-03-08T12:33:05Z
Fatal error: Ustar 
[ftp://ftp.openbsd.org/pub/OpenBSD/5.7/packages/amd64/gcal-3.6.3p0.tgz][?]: 
Error while reading header
 at /usr/libdata/perl5/OpenBSD/Ustar.pm line 89.

One solution is for pkg_add(1) to silently omit the attempt to copy the 
package to an unwritable $PKG_CACHE.  Below is a diff that achieves this, 
and modifies pkg_add(1)'s man page accordingly.

Index: pkg_add.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
retrieving revision 1.132
diff -u -p -r1.132 pkg_add.1
--- pkg_add.1   16 Apr 2015 20:01:39 -  1.132
+++ pkg_add.1   7 Jul 2015 00:51:22 -
@@ -371,7 +371,7 @@ Don't actually install a package, just r
 would be taken if it was.
 Will still copy packages to
 .Ev PKG_CACHE
-if applicable.
+if applicable, and if pkg_add has write permission to that directory.
 .It Fl P Ar type
 Check permissions for distribution, where
 .Ar type
Index: OpenBSD/PackageRepository.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
retrieving revision 1.113
diff -u -p -r1.113 PackageRepository.pm
--- OpenBSD/PackageRepository.pm4 Mar 2015 13:55:32 -   1.113
+++ OpenBSD/PackageRepository.pm7 Jul 2015 00:51:22 -
@@ -534,7 +534,7 @@ sub open_pipe
$object-{pid2} = $pid2;
} else {
open STDERR, '', $object-{errors};
-   if (defined $object-{cache_dir}) {
+   if (defined $object-{cache_dir} and -w $object-{cache_dir}) {
my $pid3 = open(my $in, -|);
$self-did_it_fork($pid3);
if ($pid3) {



Re: unwritable PKG_CACHE directory

2015-07-06 Thread lists
You're right, this most probably needs a fix.

 However, if pkg_add(1) does not have write permission to 
 $PKG_CACHE, then unclear error messages are produced.

So, there is an error which makes you think.

You notice and consider something is not that right, then go to address
the issue.

In the best possible way you can, or plead for help or just fix it
yourself, depending on your perseverance.

 One solution is for pkg_add(1) to silently omit the attempt to copy
 the package to an unwritable $PKG_CACHE.

Probably other solutions exist, some may be better.

Logically you would be setting this variable in the first place to get
the packages cached.

The end result with the change proposed would be to hide the problem you
have with permissions for $PKG_CACHE. In the end you will not be
caching anything.

Why would your proposed change be the best solution then, when it hides
the problem, instead of fixing it completely?

Please see the principle instead of minutia.



Re: unwritable PKG_CACHE directory

2015-07-06 Thread Dale Lindskog
On Tue, 7 Jul 2015, li...@wrant.com wrote:

  One solution is for pkg_add(1) to silently omit the attempt to copy 
  the package to an unwritable $PKG_CACHE.
 
 The end result with the change proposed would be to hide the problem you
 have with permissions for $PKG_CACHE. In the end you will not be
 caching anything.

You will cache every package you install.  You need to be root to install 
a package, and in my test root has write permission even when the write 
bit isn't set.  I confirmed also that Perl's '-w' returns true on a 
directory even when write permission is completely removed from that 
directory.

 Why would your proposed change be the best solution then, when it hides
 the problem, instead of fixing it completely?

It isn't hidden: in my diff, the man page indicates that, for the -n 
option, caching is conditional on the directory being writable by the 
invoker.



Re: unwritable PKG_CACHE directory

2015-07-06 Thread Dale Lindskog
On Mon, 6 Jul 2015, Dale Lindskog wrote:

 I confirmed also that Perl's '-w' returns true on a directory even when 
 write permission is completely removed from that directory.

I should have said:

I confirmed also that, *when the Perl program is run by root*, Perl's '-w' 
returns true on a directory even when write permission is completely 
removed from that directory.



Re: unwritable PKG_CACHE directory

2015-07-06 Thread Dale Lindskog
On Mon, 6 Jul 2015, Chris Bennett wrote:

 If you don't have root access, should you really be installing packages?

It is impossible to install packages when you are not root.  pkg_add won't 
let you.

This isn't about installing packages without root access.  This is about 
the -n and -s options, which I often run as a non-root user.  The -n and 
-s options don't actually install packages.



Re: unwritable PKG_CACHE directory

2015-07-06 Thread Chris Bennett
On Mon, Jul 06, 2015 at 07:15:06PM -0600, Dale Lindskog wrote:
 It is discouraged but possible to run pkg_add(1) with -n or -s as a user 
 other than root.  However, if pkg_add(1) does not have write permission to 
 $PKG_CACHE, then unclear error messages are produced.  For example:
 
 $ ls -ld $PKG_CACHE
 drwxr-xr-x  2 root  wheel  3072 Jul  2 12:13 /var/pkg_cache
 $ pkg_add -vn gcal
 pkg_add should be run as root
 Update candidates: quirks-2.54 - quirks-2.54
 quirks-2.54 signed on 2015-03-08T12:33:05Z
 Fatal error: Ustar 
 [ftp://ftp.openbsd.org/pub/OpenBSD/5.7/packages/amd64/gcal-3.6.3p0.tgz][?]: 
 Error while reading header
  at /usr/libdata/perl5/OpenBSD/Ustar.pm line 89.
 

Fatal error: Ustar, etc
means that the file transfer failed. It happens.
If it happens way too much, make a directory and download all the
packages with something like wget, which tries many times when
connections break. Set that folder as PKG_PATH and
another as PKG_CACHE. export PKG_PATH=/home/dude/packages
export PKG_CACHE=/home/dude/pkg_cache

I do this frequently with gigantic packages such as tex and jdk.

I suggest that you change to using an http server.
If you want to have a writable PKG_CACHE, why not do something simple
like /home/dude/pkg_cache?

If you don't have root access, should you really be installing packages?
Pass the request upwards. There may be valid reasons NOT to install
certain packages. They do not get the full security audit like the base
system.

If you have cut off remote root access for security reasons, get an IP
KVM hooked up for the few times you need root access

Chris Bennett