Re: Unexpected permission denied

[Max Nikulin]

On 26/01/2023 11:04, Greg Wooledge wrote:

On Thu, Jan 26, 2023 at 10:26:34AM +0700, Max Nikulin wrote:

Greg, I agree with your warnings. Just out of curiosity, is there a reason
why the following variant may still be unsafe?

runas() { local who=$1; shift; su --login "$who" --shell=/bin/bash
--command='"$0" "$@"' -- "$@"; }


1) http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html


Greg, thank you for the link. Actually I use su namely to create PAM 
session, e.g. to get shell inside a container using "lxc-attach -n 
container ... -- su - user" (when where is no point to use ssh). setpriv 
is likely not an option in such case. Mostly I use sudo. Sometimes I use 
the trick with positional arguments passed to "sh -c", but I have never 
combined it with su before.



3) --command='"$0" "$@"' is ... very unintuitive, even for an experienced
shell user.

...

su "$who" -c '"$@"' -- x "$@"


To get meaningful command name in ps output, perhaps it is better to use 
something like


su "$who" -c '"$@"' -- su-bash "$@"

(or "su-$SHELL" that skill may not be precise). Repeating $1 is likely 
worse, since the process is shell, not the passed command.


su "$who" -c '"$@"' -- "$1" "$@"


Can't say
I've ever seen su contortions like this before.


I have an idea what should be referred to as a real abuse of su. Do not 
do it, it is just a joke. However it allows to avoid issues with spaces 
and other shell specials in arguments.


runas() { local who=$1; exe="$(type -P "$2")"; shift 2; su - "$who" -s 
"$exe" -- "$@"; }

Re: Unexpected permission denied

[Greg Wooledge]

On Thu, Jan 26, 2023 at 10:26:34AM +0700, Max Nikulin wrote:
> Greg, I agree with your warnings. Just out of curiosity, is there a reason
> why the following variant may still be unsafe?
> 
> runas() { local who=$1; shift; su --login "$who" --shell=/bin/bash
> --command='"$0" "$@"' -- "$@"; }

1) http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html

2) --login is a TERRIBLE option.  It's the same as "su -" which is just
   as terrible (portably terrible).  It causes your command to be preceded
   by the reading of some user's dot file.  Why would you ever want that?
   You have no idea what will happen.  You have no idea what's in that file.

   I call this "Oracle poisoning" because it seems to be a favorite of
   Oracle database users.  Their documentation is full of this crap.
   Apparently their software doesn't work properly unless you set a bunch
   of environment variables, and they somehow came to the idea that the
   best place to set those environment variables was in some user's
   shell's dot files, and to have those files be read in by mission-
   critical scripts like the ones that start the database at boot time.

   Horrifying.

3) --command='"$0" "$@"' is ... very unintuitive, even for an experienced
   shell user.  I think I see what you're doing there, but it took me
   several minutes and some experimentation to work it out.

   I'm not sure if this variant is any clearer:

   su "$who" -c '"$@"' -- x "$@"

   Both forms will definitely confuse a novice.  For those reading along,
   the first key is that the -- is being processed by su, not by the
   shell.  The shell ends up seeing one of these forms:

   bash -c '"$0" "$@"' my command here
   bash -c '"$@"' x my command here

   The second key is that the -c option is followed by a script, and
   then by that script's $0 (a placeholder), and then by that script's
   positional parameters (which end up in "$@").  Max is forcing the
   script to use the $0 placeholder as part of the command.  My variant
   is inserting an explicit placeholder in front of the command.

   As far as "safety" goes... I think this part passes muster.  Can't say
   I've ever seen su contortions like this before.  Most people would just
   use sudo or setpriv instead, unless the aim is portability, in which
   case you would be using su's portable options (-c) rather than the
   non-portable --long-options.

4) http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html

   Seriously.

Re: Unexpected permission denied

[Max Nikulin]

On 25/01/2023 21:52, Greg Wooledge wrote:

On Wed, Jan 25, 2023 at 03:36:33PM +0100, Yassine Chaouche wrote:

runas_wwwdata ()
{
 echo su - www-data -s /bin/bash -c "$*";
 su - www-data -s /bin/bash -c "$*"
}

...

su(1) is pretty much the WORST possible choice for this, as it forces
you to launch a shell, instead of just executing a command directly.

...

unicorn:~# runas() { local who=$1; shift; su - "$who" -s /bin/bash -c "$*"; }
unicorn:~# runas www-data ls -ld /tmp/'file with spaces'
su: warning: cannot change directory to /var/www: No such file or directory


Greg, I agree with your warnings. Just out of curiosity, is there a 
reason why the following variant may still be unsafe?


runas() { local who=$1; shift; su --login "$who" --shell=/bin/bash 
--command='"$0" "$@"' -- "$@"; }

Re: Unexpected permission denied

[Jeffrey Walton]

On Wed, Jan 25, 2023 at 2:54 AM jeremy ardley  wrote:
>
> [...]
> Rechecked, thanks. The vendor directory didn't have x permissions.
> Fixed. Now to track down all the other files similarly afflicted in the
> screaming pile of manure called drupal.
>
> root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor
> drw-rw-rw- 51 www-data www-data 4096 Jan 24 12:48
> var/www/grammartiste.com/web/vendor
> root@gram01:/# chmod 0555 var/www/grammartiste.com/web/vendor
> root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor
> dr-xr-xr-x 51 www-data www-data 4096 Jan 24 12:48
> var/www/grammartiste.com/web/vendor
> root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor/autoload.php
> -r-xr-xr-x 1 www-data www-data 771 Jan 24 13:00
> var/www/grammartiste.com/web/vendor/autoload.php

Mediawiki is the same. We have a script that resets all ownership and
permissions for our website.

Gottal love it when a tarball distributes files with scripts that lack
+x, or jpegs and pngs that have +x.

Jeff

Re: Unexpected permission denied

[Jeffrey Walton]

On Wed, Jan 25, 2023 at 2:34 AM  wrote:
>
> On Wed, Jan 25, 2023 at 02:51:05PM +0800, jeremy ardley wrote:
>
> [...]
>
> >  0.41 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
> > 0x7fffdc580970) = -1 EACCES (Permission denied)
> >  0.34 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
> > 0x7fffdc57f900) = -1 EACCES (Permission denied)
>
> Quoting the lstat(2) man page:
>
>These  functions  return  information  about a file, in the
>buffer pointed to by statbuf.  No permissions are required
>on the file itself, but—in the case of stat(), fstatat(),
>and lstat()—execute (search) permission is required on all
>of the directories in pathname that lead to the file.
>
> So first I'd check the whole path leading to the file for dir
> search (aka execute) permissions.
>
> > -rwxrwxrwx 1 www-data www-data 771 Jan 24 13:00 
> > /var/www/grammartiste.com/web/vendor/autoload.php

And check permissions with `ls -AlZ` or equivalent. Selinux might be
hijacking the EACCES error code. (If selinux is enabled).

Jeff

Re: Unexpected permission denied

[Nicolas George]

Greg Wooledge (12023-01-25):
> When investigating permissions, there's really no reason to do the
> investigation as a non-root user.

When investigating permissions, doing your tests as root instead of the
user who is having the permissions issues, is a sure way for hiding the
issue.

Nothing to add with the rest of what you wrote, converting to string and
re-parsing with a shell is a terrible practice.

Regards,

-- 
  Nicolas George

Re: Unexpected permission denied

[Greg Wooledge]

On Wed, Jan 25, 2023 at 03:36:33PM +0100, Yassine Chaouche wrote:
> Le 1/25/23 à 3:22 PM, Nicolas George a écrit :
> > For the current problem:
> > 
> > sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php
> > 
> > … will cause the command to be executed in an environment closer to the
> > one that causes the problem, and therefore is more likely to reveal it.
> > Use any command of your choice instead of sudo of course.
> 
> I only have su on my server,
> I have this little bash function in one of my bash rc files.
> 
> root#cloud 15:32:53 ~ # type runas_wwwdata
> runas_wwwdata is a function
> runas_wwwdata ()
> {
> echo su - www-data -s /bin/bash -c "$*";
> su - www-data -s /bin/bash -c "$*"
> }

When investigating permissions, there's really no reason to do the
investigation as a non-root user.  It's easier to see the whole picture
if you do it as root.  Other users may have sections blocked off.

That said, you should also have setpriv(1) on your system, which you
could use for running programs as a de-privileged user, should you feel
a need for that.

su(1) is pretty much the WORST possible choice for this, as it forces
you to launch a shell, instead of just executing a command directly.

Your runas_wwwdata function is doing the same thing -- forcing the
command to be smashed into a string, and then re-parsed by a shell.
This is going to cause you enormous grief at some point; I can practically
guarantee it.

It's really easy to come up with an example that breaks this approach:

unicorn:~$ touch /tmp/'file with spaces'
unicorn:~$ sudo -s
[sudo] password for greg: 
unicorn:~# runas() { local who=$1; shift; su - "$who" -s /bin/bash -c "$*"; }
unicorn:~# runas www-data ls -ld /tmp/'file with spaces'
su: warning: cannot change directory to /var/www: No such file or directory
ls: cannot access '/tmp/file': No such file or directory
ls: cannot access 'with': No such file or directory
ls: cannot access 'spaces': No such file or directory

Smashing all of a command's arguments into a string (with no special
handling for whitespace and globbing characters) and then re-parsing it
with a shell is simply a bad idea.  Try to avoid it whenever possible.

Tools that execute a command directly don't suffer from this issue.  sudo
is one such tool.  setpriv is another, and is standard on all Debian
systems.

unicorn:~# setpriv --reuid www-data --regid www-data --clear-groups ls -ld 
/tmp/'file with spaces'
-rw-r--r-- 1 greg greg 0 Jan 25 09:50 '/tmp/file with spaces'

Not a pretty command, admittedly, but you could easily write a wrapper
for it.

Re: Unexpected permission denied

[Yassine Chaouche]

Le 1/25/23 à 3:22 PM, Nicolas George a écrit :

For the current problem:

sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php

… will cause the command to be executed in an environment closer to the
one that causes the problem, and therefore is more likely to reveal it.
Use any command of your choice instead of sudo of course.


I only have su on my server,
I have this little bash function in one of my bash rc files.

root#cloud 15:32:53 ~ # type runas_wwwdata
runas_wwwdata is a function
runas_wwwdata ()
{
echo su - www-data -s /bin/bash -c "$*";
su - www-data -s /bin/bash -c "$*"
}
root#cloud 15:32:59 ~ # runas_wwwdata  namei -l 
/var/www/nextcloud/3rdparty/autoload.php
su - www-data -s /bin/bash -c namei -l /var/www/nextcloud/3rdparty/autoload.php
f: /var/www/nextcloud/3rdparty/autoload.php
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x www-data www-data nextcloud
drwxr-xr-x www-data www-data 3rdparty
-rw-r--r-- www-data www-data autoload.php
root#cloud 15:33:03 ~ #


I could have passed www-data as a parameter,
but since it's the only user i need to run commands under for the time being,
defining it that way allows me to type "run"
then 
and then whatever command I need to run.
Saves a couple key strokes.

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: Unexpected permission denied

[Nicolas George]

Yassine Chaouche (12023-01-25):
> I prefer to use namei -l.

namei is good indeed.

> root@cloud[10.10.10.84/24] 15:15:43 ~ # namei -l 
> /var/www/nextcloud/3rdparty/autoload.php

For the current problem:

sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php

… will cause the command to be executed in an environment closer to the
one that causes the problem, and therefore is more likely to reveal it.
Use any command of your choice instead of sudo of course.

Regards,

-- 
  Nicolas George

Re: Unexpected permission denied

[Yassine Chaouche]

Le 1/25/23 à 2:07 PM, Greg Wooledge a écrit :

On Wed, Jan 25, 2023 at 07:34:54AM -0500, Dan Ritter wrote:

jeremy ardley wrote:

I have vague memories there are more file flags in newer Linux file systems?


There are extended attributes, of which the only one you are
likely to encounter is i, immutable. It is occasionally useful
to nail down the state of a file even when something properly
has write permissions for it.

lsattr and chattr are the relevant commands.


You've got the standard Unix permissions, rwx.

You've got Linux's "attributes", lsattr(1) and friends.

You've got ACLs, getfacl(1) and friends.

You've got AppArmor, which can cause Permission denied errors on files
outside of a program's designated working areas.  This usually crops up
when someone tries to move stuff to a different location in the file
system(s) with a symlink to the new location.

You've got systemd's restrictions which may be placed upon a service --
see for example ProtectHome= in systemd.exec(5).

Plus whatever else is out there that I'm not even aware of.  SELinux?



how about auditd?

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: Unexpected permission denied

[Yassine Chaouche]

Le 1/25/23 à 8:44 AM, jeremy ardley a écrit :


Anyway tree permissions:

root@gram01:/# ls -ld var

drwxr-xr-x 12 root root 4096 Nov  7 23:30 var

root@gram01:/# ls -ld var/www

drwxr-xr-x 5 www-data www-data 4096 Jan 23 16:33 var/www

root@gram01:/# ls -ld var/www/grammartiste.com/

drwxr-xr-x 5 www-data www-data 4096 Jan 24 12:51 var/www/grammartiste.com/

root@gram01:/# ls -ld var/www/grammartiste.com/web

drwxr-xr-x 8 www-data www-data 4096 Jan 24 14:54 var/www/grammartiste.com/web

root@gram01:/# ls -ld var/www/grammartiste.com/web/autoload.php

-rwxr-xr-x 1 www-data www-data 312 Jan 24 13:27 
var/www/grammartiste.com/web/autoload.php

root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor/autoload.php

-r-xr-xr-x 1 www-data www-data 771 Jan 24 13:00 
var/www/grammartiste.com/web/vendor/autoload.php


I have vague memories there are more file flags in newer Linux file systems?

Jeremy



I prefer to use namei -l.
Example usage:

root@cloud[10.10.10.84/24] 15:15:43 ~ # namei -l 
/var/www/nextcloud/3rdparty/autoload.php
f: /var/www/nextcloud/3rdparty/autoload.php
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x www-data www-data nextcloud
drwxr-xr-x www-data www-data 3rdparty
-rw-r--r-- www-data www-data autoload.php
root@cloud[10.10.10.84/24] 15:16:10 ~ #


--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: Unexpected permission denied

[Thomas Schmitt]

Hi,

jeremy ardley wrote:
> > > I have vague memories there are more file flags in newer Linux file 
> > > systems?

Dan Ritter wrote:
> > There are extended attributes, [...]
> > lsattr and chattr are the relevant commands.

Nicolas George wrote:
> What you describe are file attributes specific to the ext2/3/4
> filesystems. They are not called “extended attributes” because extended
> attributes are something else.

Indeed. The command to inquire extended attributes is getfattr(1).
General info is at attr(5).


> crw-rw+  1 root video81, 3 Jan 25 08:33 video3
> The + at the end of the permissions means there are ACLs on these
> devices, allowing the console user to access them. ACLs are implemented
> using extended attributes.

getfacl(1) shows ACL (and POSIX permissions). See also acl(5).

(Then there is getcap(8) which shows what is described in capabilities(7).
Linux file capabilities are curbs for the superuser. I am not aware that
they would restrict access or execution of particular files.)


Have a nice day :)

Thomas

Re: Unexpected permission denied

[Greg Wooledge]

On Wed, Jan 25, 2023 at 07:34:54AM -0500, Dan Ritter wrote:
> jeremy ardley wrote: 
> > I have vague memories there are more file flags in newer Linux file systems?
> 
> There are extended attributes, of which the only one you are
> likely to encounter is i, immutable. It is occasionally useful
> to nail down the state of a file even when something properly
> has write permissions for it.
> 
> lsattr and chattr are the relevant commands.

You've got the standard Unix permissions, rwx.

You've got Linux's "attributes", lsattr(1) and friends.

You've got ACLs, getfacl(1) and friends.

You've got AppArmor, which can cause Permission denied errors on files
outside of a program's designated working areas.  This usually crops up
when someone tries to move stuff to a different location in the file
system(s) with a symlink to the new location.

You've got systemd's restrictions which may be placed upon a service --
see for example ProtectHome= in systemd.exec(5).

Plus whatever else is out there that I'm not even aware of.  SELinux?

Re: Unexpected permission denied

[Nicolas George]

Dan Ritter (12023-01-25):
> There are extended attributes, of which the only one you are
> likely to encounter is i, immutable. It is occasionally useful
> to nail down the state of a file even when something properly
> has write permissions for it.
> 
> lsattr and chattr are the relevant commands.

You are confusing two concepts.

What you describe are file attributes specific to the ext2/3/4
filesystems. They are not called “extended attributes” because extended
attributes are something else.

Extended attributes are something newer, and much more powerful. For
example :

crw-rw+  1 root kvm  10,   232 Jan 25 08:33 kvm
crw-rw-r--+  1 root netdev   10,   242 Jan 25 08:33 rfkill
crw-rw+  1 root video81, 0 Jan 25 08:33 video0
crw-rw+  1 root video81, 1 Jan 25 08:33 video1
crw-rw+  1 root video81, 2 Jan 25 08:33 video2
crw-rw+  1 root video81, 3 Jan 25 08:33 video3

The + at the end of the permissions means there are ACLs on these
devices, allowing the console user to access them. ACLs are implemented
using extended attributes. The fancy security systems like SE Linux use
them too.

Regards,

-- 
  Nicolas George

Re: Unexpected permission denied

[Dan Ritter]

jeremy ardley wrote: 
> I have vague memories there are more file flags in newer Linux file systems?

There are extended attributes, of which the only one you are
likely to encounter is i, immutable. It is occasionally useful
to nail down the state of a file even when something properly
has write permissions for it.

lsattr and chattr are the relevant commands.

-dsr-

Re: Unexpected permission denied

[tomas]

On Wed, Jan 25, 2023 at 03:53:50PM +0800, jeremy ardley wrote:

[...]

> Rechecked, thanks. The vendor directory didn't have x permissions. Fixed.
> Now to track down all the other files similarly afflicted in the screaming
> pile of manure called drupal.

uh-oh ;-)

Cheers & good luck
-- 
t


signature.asc
Description: PGP signature

Re: Unexpected permission denied

[jeremy ardley]

On 25/1/23 15:44, jeremy ardley wrote:

On 25/1/23 15:33, to...@tuxteam.de wrote:

On Wed, Jan 25, 2023 at 02:51:05PM +0800, jeremy ardley wrote:

[...]

  0.41 
lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc580970) = -1 EACCES (Permission denied)
  0.34 
lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc57f900) = -1 EACCES (Permission denied)

Quoting the lstat(2) man page:

    These  functions  return  information  about a file, in the
    buffer pointed to by statbuf.  No permissions are required
    on the file itself, but—in the case of stat(), fstatat(),
    and lstat()—execute (search) permission is required on all
    of the directories in pathname that lead to the file.

So first I'd check the whole path leading to the file for dir
search (aka execute) permissions.

-rwxrwxrwx 1 www-data www-data 771 Jan 24 13:00 
/var/www/grammartiste.com/web/vendor/autoload.php

Ugh ;-)

The 777 was simply a hack to try and resolve the problem. Now removed 
to avoid offence.


Anyway tree permissions:

root@gram01:/# ls -ld var

drwxr-xr-x 12 root root 4096 Nov  7 23:30 var

root@gram01:/# ls -ld var/www

drwxr-xr-x 5 www-data www-data 4096 Jan 23 16:33 var/www

root@gram01:/# ls -ld var/www/grammartiste.com/

drwxr-xr-x 5 www-data www-data 4096 Jan 24 12:51 
var/www/grammartiste.com/


root@gram01:/# ls -ld var/www/grammartiste.com/web

drwxr-xr-x 8 www-data www-data 4096 Jan 24 14:54 
var/www/grammartiste.com/web


root@gram01:/# ls -ld var/www/grammartiste.com/web/autoload.php

-rwxr-xr-x 1 www-data www-data 312 Jan 24 13:27 
var/www/grammartiste.com/web/autoload.php


root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor/autoload.php

-r-xr-xr-x 1 www-data www-data 771 Jan 24 13:00 
var/www/grammartiste.com/web/vendor/autoload.php





Rechecked, thanks. The vendor directory didn't have x permissions. 
Fixed. Now to track down all the other files similarly afflicted in the 
screaming pile of manure called drupal.


root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor
drw-rw-rw- 51 www-data www-data 4096 Jan 24 12:48 
var/www/grammartiste.com/web/vendor

root@gram01:/# chmod 0555 var/www/grammartiste.com/web/vendor
root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor
dr-xr-xr-x 51 www-data www-data 4096 Jan 24 12:48 
var/www/grammartiste.com/web/vendor

root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor/autoload.php
-r-xr-xr-x 1 www-data www-data 771 Jan 24 13:00 
var/www/grammartiste.com/web/vendor/autoload.php



Jeremy

Re: Unexpected permission denied

[jeremy ardley]

On 25/1/23 15:33, to...@tuxteam.de wrote:

On Wed, Jan 25, 2023 at 02:51:05PM +0800, jeremy ardley wrote:

[...]


  0.41 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc580970) = -1 EACCES (Permission denied)
  0.34 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc57f900) = -1 EACCES (Permission denied)

Quoting the lstat(2) man page:

These  functions  return  information  about a file, in the
buffer pointed to by statbuf.  No permissions are required
on the file itself, but—in the case of stat(), fstatat(),
and lstat()—execute (search) permission is required on all
of the directories in pathname that lead to the file.

So first I'd check the whole path leading to the file for dir
search (aka execute) permissions.


-rwxrwxrwx 1 www-data www-data 771 Jan 24 13:00 
/var/www/grammartiste.com/web/vendor/autoload.php

Ugh ;-)

The 777 was simply a hack to try and resolve the problem. Now removed to 
avoid offence.


Anyway tree permissions:

root@gram01:/# ls -ld var

drwxr-xr-x 12 root root 4096 Nov  7 23:30 var

root@gram01:/# ls -ld var/www

drwxr-xr-x 5 www-data www-data 4096 Jan 23 16:33 var/www

root@gram01:/# ls -ld var/www/grammartiste.com/

drwxr-xr-x 5 www-data www-data 4096 Jan 24 12:51 var/www/grammartiste.com/

root@gram01:/# ls -ld var/www/grammartiste.com/web

drwxr-xr-x 8 www-data www-data 4096 Jan 24 14:54 var/www/grammartiste.com/web

root@gram01:/# ls -ld var/www/grammartiste.com/web/autoload.php

-rwxr-xr-x 1 www-data www-data 312 Jan 24 13:27 
var/www/grammartiste.com/web/autoload.php

root@gram01:/# ls -ld var/www/grammartiste.com/web/vendor/autoload.php

-r-xr-xr-x 1 www-data www-data 771 Jan 24 13:00 
var/www/grammartiste.com/web/vendor/autoload.php


I have vague memories there are more file flags in newer Linux file systems?

Jeremy

Re: Unexpected permission denied

[tomas]

On Wed, Jan 25, 2023 at 02:51:05PM +0800, jeremy ardley wrote:

[...]

>  0.41 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
> 0x7fffdc580970) = -1 EACCES (Permission denied)
>  0.34 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
> 0x7fffdc57f900) = -1 EACCES (Permission denied)

Quoting the lstat(2) man page:

   These  functions  return  information  about a file, in the
   buffer pointed to by statbuf.  No permissions are required
   on the file itself, but—in the case of stat(), fstatat(),
   and lstat()—execute (search) permission is required on all
   of the directories in pathname that lead to the file.

So first I'd check the whole path leading to the file for dir
search (aka execute) permissions.

> -rwxrwxrwx 1 www-data www-data 771 Jan 24 13:00 
> /var/www/grammartiste.com/web/vendor/autoload.php

Ugh ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Unexpected permission denied

[jeremy ardley]

I am having trouble with php8.1-fpm commanded from nginx on a bullseye 
system


php8.1-fpm reports access denied when opening a specific file for the 
application. The file has universal rwx permissions (after attempting to 
fix problem). I am not running selinux but I do see some references to 
apparmor in the logs.


This is the relevant part of the strace

 0.00 accept(10, {sa_family=AF_UNIX}, [112->2]) = 5
 6.306001 poll([{fd=5, events=POLLIN}], 1, 5000) = 1 ([{fd=5, 
revents=POLLIN}])
 0.50 times({tms_utime=1, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 
1736216570
 0.29 read(5, "\1\1\0\1\0\10\0\0", 8) = 8
 0.24 read(5, "\0\1\0\0\0\0\0\0", 8) = 8
 0.20 read(5, "\1\4\0\1\5\304\4\0", 8) = 8
 0.17 read(5, "\f\0QUERY_STRING\16\3REQUEST_METHODGE"..., 1480) = 1480
 0.21 read(5, "\1\4\0\1\0\0\0\0", 8) = 8
 0.60 lstat("/var/www/grammartiste.com/web/index.php", 
{st_mode=S_IFREG|0755, st_size=549, ...}) = 0
 0.40 lstat("/var/www/grammartiste.com/web", {st_mode=S_IFDIR|0755, 
st_size=4096, ...}) = 0
 0.24 lstat("/var/www/grammartiste.com", {st_mode=S_IFDIR|0755, 
st_size=4096, ...}) = 0
 0.21 lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
 0.20 lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
 0.70 stat("/var/www/grammartiste.com/web/.user.ini", 0x7fffdc584000) = 
-1 ENOENT (No such file or directory)
 0.000119 rt_sigaction(SIGPROF, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.36 rt_sigaction(SIGHUP, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.22 rt_sigaction(SIGINT, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.20 rt_sigaction(SIGQUIT, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.19 rt_sigaction(SIGTERM, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.19 rt_sigaction(SIGUSR1, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.19 rt_sigaction(SIGUSR2, NULL, {sa_handler=0x55d9525d9fb0, 
sa_mask=~[ILL TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN 
RT_1], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, 8) = 0
 0.20 setitimer(ITIMER_PROF, {it_interval={tv_sec=0, tv_usec=0}, 
it_value={tv_sec=60, tv_usec=0}}, NULL) = 0
 0.20 rt_sigaction(SIGPROF, {sa_handler=0x55d9525d9fb0, sa_mask=~[ILL 
TRAP ABRT BUS FPE KILL SEGV CONT STOP TSTP TTIN TTOU SYS RTMIN RT_1], 
sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc72ecdbd60}, NULL, 8) = 0
 0.18 rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
 0.000118 getcwd("/", 4095) = 2
 0.20 chdir("/var/www/grammartiste.com/web") = 0
 0.41 setitimer(ITIMER_PROF, {it_interval={tv_sec=0, tv_usec=0}, 
it_value={tv_sec=30, tv_usec=0}}, NULL) = 0
 0.19 fcntl(3, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1, 
l_len=1}) = 0
 0.29 stat("/var/www/grammartiste.com/web/index.php", 
{st_mode=S_IFREG|0755, st_size=549, ...}) = 0
 0.34 getcwd("/var/www/grammartiste.com/web", 4096) = 30
 0.30 stat("/var/www/grammartiste.com/web/autoload.php", 
{st_mode=S_IFREG|0755, st_size=312, ...}) = 0
 0.41 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc580970) = -1 EACCES (Permission denied)
 0.34 lstat("/var/www/grammartiste.com/web/vendor/autoload.php", 
0x7fffdc57f900) = -1 EACCES (Permission denied)
 0.21 lstat("/var/www/grammartiste.com/web/vendor", 
{st_mode=S_IFDIR|0666, st_size=4096, ...}) = 0
 0.21 openat(AT_FDCWD, 
"/var/www/grammartiste.com/web/vendor/autoload.php", O_RDONLY) = -1 EACCES 
(Permission denied)
 0.67 write(2, "NOTICE: sapi_cgi_log_message(), "..., 227) = 227
 0.56 write(2, "NOTICE: sapi_cgi_log_message(), "..., 400) = 400
 0.22 chdir("/")    = 0
 0.19 times({tms_utime=1, tms_stime=0, tms_cutime=0

Re: Question on permission denied (public key)

[john doe]

On 12/6/2021 9:32 AM, Adriel Peng wrote:

Hello

Sorry this is maybe not the debian question...

I have changed my github username today, after that I run this command in
local machine to update the remote url:

git remote set-url origin new.git.url/here

And I even run these two in local repo:

   git config --global user.email "n...@mail.com"
   git config --global user.name "new-username"

After doing those when I run git pull it always gets:

$ git pull
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

But, ssh -T g...@github.com works and it shows me the new user space.
Can you tell me how to fix this?


Not realy but here's some hints:
- Are you using the 'gh' utility?
- What did you change before the previous working URI and the not
working one?

--
John Doe

Question on permission denied (public key)

[Adriel Peng]

Hello

Sorry this is maybe not the debian question...

I have changed my github username today, after that I run this command in
local machine to update the remote url:

git remote set-url origin new.git.url/here

And I even run these two in local repo:

  git config --global user.email "n...@mail.com"
  git config --global user.name "new-username"

After doing those when I run git pull it always gets:

$ git pull
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

But, ssh -T g...@github.com works and it shows me the new user space.
Can you tell me how to fix this?

Thanks a lot.

Re: Re: Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Simon Bernier St-Pierre]

Thanks a ton!

I'm running this container on my private network behind a NAT, so I'm 
not too worried about disabling apparmor. I ended up just giving as 
loose of a configuration I could and it did the trick.


lxc.apparmor.profile = unconfined
lxc.apparmor.allow_nesting = 1
lxc.apparmor.allow_incomplete = 1

The first line alone did not seem to do the trick, so I added 2 and 3 
and it worked. Good enough for me.


Thanks again!

Re: Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Reco]

Hi.

On Tue, Jul 16, 2019 at 10:57:06PM -0400, Simon Bernier St-Pierre wrote:
> I have a LXC container which is connected to a remote VPN using
> OpenVPN. After upgrading to buster, the VPN does not start anymore.
> I'm using Debian buster on my host OS

These are relevant to the problem.

> This is the journalctl log for the openvpn service:
...
> Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed to
> set up mount namespacing: Permission denied

And that is too.
As usual with this kind of problems, journalctl log is useless. What you
need is auditd log, because...

The most probable reasons of this are ProtectSystem=true in openvpn's
systemd unit (so systemd tries to setup a separate mount namespace for a
process), and an LXC Apparmor policy that started to work in buster (it
did not in stretch).

So, you have three options:

1) Set lxc.apparmor.profile = lxc-container-default-with-nesting for
your container. It may or may not help.

2) Disable Apparmor for LXC altogether (bad idea):
lxc.apparmor.profile = unconfined

3) Execute aa-logprof ("apparmor-utils" package) and stare into that
abyss.

Reco

Issue with OpenVPN inside a LXC container: Failed at step NAMESPACE spawning /usr/sbin/openvpn: Permission denied

[Simon Bernier St-Pierre]

I have a LXC container which is connected to a remote VPN using OpenVPN. 
After upgrading to buster, the VPN does not start anymore.


I'm using Debian buster on my host OS and Debian buster on the guest OS. 
Both were updated from stretch. Aside from OpenVPN there's only deluged 
and deluge-web that are installed.


This is the journalctl log for the openvpn service:

root@dl:/# journalctl -u openvpn-client@pia.service
-- Logs begin at Tue 2019-07-16 20:32:30 EDT, end at Tue 2019-07-16 
22:31:19 EDT. --

Jul 16 20:32:30 dl systemd[1]: Starting OpenVPN tunnel for pia...
Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed to 
set up mount namespacing: Permission denied
Jul 16 20:32:30 dl systemd[70]: openvpn-client@pia.service: Failed at 
step NAMESPACE spawning /usr/sbin/openvpn: Permission denied
Jul 16 20:32:30 dl systemd[1]: openvpn-client@pia.service: Main process 
exited, code=exited, status=226/NAMESPACE
Jul 16 20:32:30 dl systemd[1]: openvpn-client@pia.service: Failed with 
result 'exit-code'.

Jul 16 20:32:30 dl systemd[1]: Failed to start OpenVPN tunnel for pia.

I've searched online but I haven't found anything relevant to my situation.

Anything to help me figure this one out will be greatly appreciated. Thanks!

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Reco]

Hi.

On Thu, Oct 18, 2018 at 06:11:13AM +0200, steve wrote:
> Le 17-10-2018, à 09:52:06 +0300, Reco a écrit :
> 
> > > > And, finally, /var/log/audit/audit.log if you have auditd installed
> > > > (hint - install it if you don't).
> > > 
> > > grep apache /var/log/audit/audit.log
> > > 
> > > type=AVC msg=audit(1539750555.347:76): apparmor="DENIED" operation="open" 
> > > profile="/usr/sbin/apache2" name="/etc/gai.conf" pid=17485 comm="apache2" 
> > > requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> > > type=SYSCALL msg=audit(1539750555.347:76): arch=c03e syscall=2 
> > > success=no exit=-13 a0=7fe220cac22a a1=8 a2=1b6 a3=8 items=0 
> > > ppid=17482 pid=17485 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
> > > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apache2" 
> > > exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) key=(null)
> > > type=AVC msg=audit(1539750555.347:77): apparmor="DENIED" operation="open" 
> > > profile="/usr/sbin/apache2" name="/etc/apache2/apache2.conf" pid=17485 
> > > comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> > > type=SYSCALL msg=audit(1539750555.347:77): arch=c03e syscall=2 
> > > success=no exit=-13 a0=7fe2219b6f70 a1=8 a2=1b6 a3=ff7f 
> > > items=0 ppid=17482 pid=17485 auid=4294967295 uid=0 gid=0 euid=0 suid=0 
> > > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apache2" 
> > > exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) key=(null)
> > > type=SERVICE_START msg=audit(1539750555.383:78): pid=1 uid=0 
> > > auid=4294967295 ses=4294967295 subj==unconfined msg='unit=apache2 
> > > comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? 
> > > res=failed'
> > > 
> > > Seems fine to me.
> > 
> > On the contrary. These show that apache2 binary was denied from reading
> > /etc/gai.conf *and* /etc/apache2/apache2.conf by some Mandatory Access
> > Control (audit record type AVC).
> > Since you're using Debian, I suspect AppArmor.
> > 
> > First things first, Apparmor (and any kind of MAC) is a good thing,
> > especially in your typical server environment. They'll suggest you to
> > disable it - don't. Lowering overall security of your OS is not worth
> > it.
> > 
> > Second, Debian does not provide apparmor profiles for apache. Whatever
> > profile is active in your installation is a result of local
> > misconfiguration.
> > 
> > Third, it's fixable. Install apparmor-utils.
> > Invoke 'aa-complain /usr/sbin/apache2'.
> > Start your apache2 service, stop it and start again.
> > Make some GET/PUT requests to it.
> > Invoke 'aa-logprof' and generate Apparmor profile that's uniquely suited
> > for your environment.
> 
> Here, I get
> 
> Reading log entries from /var/log/audit/audit.log.
> Updating AppArmor profiles in /etc/apparmor.d.
> Target profile exists: /etc/apparmor.d/usr.bin.nvidia-modprobe
> 
> Profile:  libreoffice-soffice
> Execute:  /usr/bin/nvidia-modprobe
> Severity: unknown
> 
> (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny 
> / Abo(r)t / (F)inish
>
> What should I be expected to do?

Skip it, of course - Unconfined.
That one's for libreoffice, and you need that dialog showing something for 
apache.


> Also, aa-status spits out
> 
> apparmor module is loaded.
> 63 profiles are loaded.
...
> 3 processes are in complain mode.
>   /usr/sbin/apache2 (11894)
>   /usr/sbin/apache2 (12019)
>   /usr/sbin/apache2 (12020)
...
> 
> This is rather confusing.

Yet here you have a legitimate Apparmor profile for apache.

> What should I do with this?

Let's try it another way.

pkill -USR1 `pidof auditd`

aa-logprof /usr/sbin/apache2


> > Invoke 'aa-enforce /usr/sbin/apache2', and you're set.
> 
> Profile for /usr/sbin/apache2 not found, skipping
> 
> I guess this is normal since I didn't finish the aa-logprof step.

More or less. aa-status does not lie, your kernel has a profile for
apache.

Reco

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[mick crane]

On 2018-10-18 07:15, steve wrote:

Le 18-10-2018, à 07:07:34 +0100, mick crane a écrit :


On 2018-10-18 05:11, steve wrote:



Still reading on this new thing for me.

Thanks

Steve


I never came across this apparmor.
did you try stopping it with systemctl then see if apache works as 
expected ?


Yes I did and apache failed to start.


does "apachectl configtest" say OK ?

--
Key ID4BFEBB31

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[mick crane]

On 2018-10-18 07:07, mick crane wrote:

On 2018-10-18 05:11, steve wrote:



Still reading on this new thing for me.

Thanks

Steve


I never came across this apparmor.
did you try stopping it with systemctl then see if apache works as 
expected ?


Ah, OK I see you tried that.
Would that not indicate problem is not apparmor ?

mick

--
Key ID4BFEBB31

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Le 18-10-2018, à 07:07:34 +0100, mick crane a écrit :


On 2018-10-18 05:11, steve wrote:



Still reading on this new thing for me.

Thanks

Steve


I never came across this apparmor.
did you try stopping it with systemctl then see if apache works as 
expected ?


Yes I did and apache failed to start.

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[mick crane]

On 2018-10-18 05:11, steve wrote:



Still reading on this new thing for me.

Thanks

Steve


I never came across this apparmor.
did you try stopping it with systemctl then see if apache works as 
expected ?


mick

--
Key ID4BFEBB31

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Le 17-10-2018, à 09:52:06 +0300, Reco a écrit :


> And, finally, /var/log/audit/audit.log if you have auditd installed
> (hint - install it if you don't).

grep apache /var/log/audit/audit.log

type=AVC msg=audit(1539750555.347:76): apparmor="DENIED" operation="open" profile="/usr/sbin/apache2" 
name="/etc/gai.conf" pid=17485 comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
type=SYSCALL msg=audit(1539750555.347:76): arch=c03e syscall=2 success=no exit=-13 
a0=7fe220cac22a a1=8 a2=1b6 a3=8 items=0 ppid=17482 pid=17485 auid=4294967295 uid=0 gid=0 
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apache2" 
exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) key=(null)
type=AVC msg=audit(1539750555.347:77): apparmor="DENIED" operation="open" profile="/usr/sbin/apache2" 
name="/etc/apache2/apache2.conf" pid=17485 comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
type=SYSCALL msg=audit(1539750555.347:77): arch=c03e syscall=2 success=no exit=-13 
a0=7fe2219b6f70 a1=8 a2=1b6 a3=ff7f items=0 ppid=17482 pid=17485 auid=4294967295 
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 
comm="apache2" exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) 
key=(null)
type=SERVICE_START msg=audit(1539750555.383:78): pid=1 uid=0 auid=4294967295 ses=4294967295 
subj==unconfined msg='unit=apache2 comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=failed'

Seems fine to me.


On the contrary. These show that apache2 binary was denied from reading
/etc/gai.conf *and* /etc/apache2/apache2.conf by some Mandatory Access
Control (audit record type AVC).
Since you're using Debian, I suspect AppArmor.

First things first, Apparmor (and any kind of MAC) is a good thing,
especially in your typical server environment. They'll suggest you to
disable it - don't. Lowering overall security of your OS is not worth
it.

Second, Debian does not provide apparmor profiles for apache. Whatever
profile is active in your installation is a result of local
misconfiguration.

Third, it's fixable. Install apparmor-utils.
Invoke 'aa-complain /usr/sbin/apache2'.
Start your apache2 service, stop it and start again.
Make some GET/PUT requests to it.
Invoke 'aa-logprof' and generate Apparmor profile that's uniquely suited
for your environment.


Here, I get

Reading log entries from /var/log/audit/audit.log.
Updating AppArmor profiles in /etc/apparmor.d.
Target profile exists: /etc/apparmor.d/usr.bin.nvidia-modprobe

Profile:  libreoffice-soffice
Execute:  /usr/bin/nvidia-modprobe
Severity: unknown

(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / 
Abo(r)t / (F)inish


What should I be expected to do?

Also, aa-status spits out

apparmor module is loaded.
63 profiles are loaded.
22 profiles are in enforce mode.
  /usr/lib/cups/backend/cups-pdf
  /usr/lib/telepathy/mission-control-5
  /usr/lib/telepathy/telepathy-*
  /usr/lib/telepathy/telepathy-*//pxgsettings
  /usr/lib/telepathy/telepathy-*//sanitized_helper
  /usr/lib/telepathy/telepathy-ofono
  /usr/sbin/cups-browsed
  /usr/sbin/cupsd
  /usr/sbin/cupsd//third_party
  /usr/sbin/libvirtd
  /usr/sbin/libvirtd//qemu_bridge_helper
  /usr/sbin/mysqld-akonadi
  /usr/sbin/mysqld-akonadi///usr/sbin/mysqld
  libreoffice-senddoc
  libreoffice-soffice//gpg
  libreoffice-xpdfimport
  thunderbird
  thunderbird//browser_java
  thunderbird//browser_openjdk
  thunderbird//gpg
  thunderbird//sanitized_helper
  virt-aa-helper
41 profiles are in complain mode.
  /usr/bin/nvidia-modprobe
  /usr/lib/dovecot/anvil
  /usr/lib/dovecot/auth
  /usr/lib/dovecot/config
  /usr/lib/dovecot/deliver
  /usr/lib/dovecot/dict
  /usr/lib/dovecot/dovecot-auth
  /usr/lib/dovecot/dovecot-lda
  /usr/lib/dovecot/dovecot-lda///usr/sbin/sendmail
  /usr/lib/dovecot/imap
  /usr/lib/dovecot/imap-login
  /usr/lib/dovecot/lmtp
  /usr/lib/dovecot/log
  /usr/lib/dovecot/managesieve
  /usr/lib/dovecot/managesieve-login
  /usr/lib/dovecot/pop3
  /usr/lib/dovecot/pop3-login
  /usr/lib/dovecot/ssl-params
  /usr/sbin/apache2
  /usr/sbin/apache2//DEFAULT_URI
  /usr/sbin/apache2//HANDLING_UNTRUSTED_INPUT
  /usr/sbin/avahi-daemon
  /usr/sbin/dnsmasq
  /usr/sbin/dnsmasq//libvirt_leaseshelper
  /usr/sbin/dovecot
  /usr/sbin/identd
  /usr/sbin/mdnsd
  /usr/sbin/nmbd
  /usr/sbin/nscd
  /usr/sbin/smbd
  /usr/sbin/smbldap-useradd
  /usr/sbin/smbldap-useradd///etc/init.d/nscd
  /usr/{sbin/traceroute,bin/traceroute.db}
  klogd
  libreoffice-oopslash
  libreoffice-soffice
libreoffice-soffice//null-/usr/bin/nvidia-modprobe
  libreoffice-soffice//null-/usr/bin/nvidia-modprobe//null-/bin/kmod
  ping
  syslog-ng
  syslogd
15 processes have profiles defined.
3 processes are in enforce mode.
  /usr/sbin/cups-browsed (25039)
  /usr/sbin/cupsd (25038)
  thunderbird (12250)
3 processes are in complain mode.
  /usr/sbin/apache2 (11894)
  /usr/sbin/apache2 (12019)
  /usr/sbin/apache2 (12020)
9 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Thanks Reco for your input.

I'll have to go trough it, but don't have time right now.


Steve

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Le 17-10-2018, à 05:38:11 +, Steve Kemp a écrit :



 To recap you reported the original error:


 apache2: Could not open configuration file /etc/apache2/apache2.conf:
 Permission denied


 Now you've provided more details, from your audit-log:


type=AVC msg=audit(1539750555.347:77): apparmor="DENIED"
operation="open" profile="/usr/sbin/apache2"
name="/etc/apache2/apache2.conf" pid=17485 comm="apache2"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0


 There you see "DENIED" along with "exit=-13".  You can lookup
the meaning of "-13" via this command but I'll guess it correpondes to
EPERM ("permission denied"):

   ausearch --interpret --exit -13

 In conclusion: You're using apparmor, it prevented the process from
opening the configuration file, which stopped the service from starting.
That was logged explicitly :)


Good point. But since I have not explicitly installed apparmor and thus
don't know how to use it (was installed during an update I guess), I
didn't really bothered.


 To fix this either:

   1.  Fix apparmor so that you can open the file.

   2.  Disable apparmor.

 The first might be as simple as `systemctl restart apparmor.service`,
that's working on the basis that:


Didn't work, same error message.


   * You had apparmor installed.
   * You've now just installed apache.


To be correct, I just reinstalled it.

Stopped apparmor then tried to start apache2, but same problem.


   * This will have given you new apparmor rules.
   * But they won't be loaded because apparmor wasn't reloaded.
   * So apache failed.

 I'm not 100% sure if that is the case, but it seems likely.  If not
you'll need to do some reading.  Perhaps start here:

   https://wiki.debian.org/AppArmor


Yeah, I think I'm gonna have to do that.

But I must say it's a bit shitty because "before", all I had to do to
run apache was 'apt install apache2'. Don't understand why this apparmor
thing is screwing my habits…

Thanks for your help and pointers.

Steve

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Reco]

Hi.

On Wed, Oct 17, 2018 at 06:33:09AM +0200, steve wrote:
> Le 16-10-2018, à 09:51:22 +0300, Reco a écrit :
> 
> > Hi.
> > 
> > On Tue, Oct 16, 2018 at 07:31:17AM +0200, steve wrote:
> > > Hi there,
> > > 
> > > Purged and then reinstalled apache2 and when I want to start apache2,
> > > here's what I get:
> > > 
> > > # systemctl status apache2.service
> > > ● apache2.service - The Apache HTTP Server
> > >   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
> > > preset: enabled)
> > >   Active: failed (Result: exit-code) since Tue 2018-10-16 07:22:02 CEST; 
> > > 13s ago
> > >  Process: 32122 ExecStart=/usr/sbin/apachectl start (code=exited, 
> > > status=1/FAILURE)
> > > 
> > > oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
> > > oct 16 07:22:01 box apachectl[32122]: apache2: Could not open 
> > > configuration file /etc/apache2/apache2.conf: Permission denied
> > > oct 16 07:22:02 box apachectl[32122]: Action 'start' failed.
> > > oct 16 07:22:02 box apachectl[32122]: The Apache error log may have more 
> > > information.
> > 
> > So, does the 'Apache error log' have anything useful?
> 
> Nothing. It's empty.

And that, my dear list, shows us that in that particular case systemd
journal is useless. It was expected though, as it's the usual thing with
it - it's able to tell you that something is wrong, but it never tells
you the actual cause of it.


> > > ls -l /etc/apache2/apache2.conf
> > > -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf
> > 
> > First things first, it's 'ls -lZ /etc/apache2/apache2.conf'.
> 
> # ls -lZ /etc/apache2/apache2.conf -rw-r--r-- 1 root root ? 7224 jun  2 10:01 
> /etc/apache2/apache2.conf

And that shows us that you aren't using SELinux.


> > Next thing to check is 'ls -ald / /etc /etc/apache2'.
> 
> # ls -ald /etc/apache2
> drwxr-xr-x 8 root root 4096 oct 16 07:21 /etc/apache2

Original command contains three directories, you show just one.
A hint - all three could be important in this case.


> > And, finally, /var/log/audit/audit.log if you have auditd installed
> > (hint - install it if you don't).
> 
> grep apache /var/log/audit/audit.log
> 
> type=AVC msg=audit(1539750555.347:76): apparmor="DENIED" operation="open" 
> profile="/usr/sbin/apache2" name="/etc/gai.conf" pid=17485 comm="apache2" 
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> type=SYSCALL msg=audit(1539750555.347:76): arch=c03e syscall=2 success=no 
> exit=-13 a0=7fe220cac22a a1=8 a2=1b6 a3=8 items=0 ppid=17482 
> pid=17485 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
> fsgid=0 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" 
> subj==/usr/sbin/apache2 (enforce) key=(null)
> type=AVC msg=audit(1539750555.347:77): apparmor="DENIED" operation="open" 
> profile="/usr/sbin/apache2" name="/etc/apache2/apache2.conf" pid=17485 
> comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> type=SYSCALL msg=audit(1539750555.347:77): arch=c03e syscall=2 success=no 
> exit=-13 a0=7fe2219b6f70 a1=8 a2=1b6 a3=ff7f items=0 
> ppid=17482 pid=17485 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
> sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apache2" 
> exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) key=(null)
> type=SERVICE_START msg=audit(1539750555.383:78): pid=1 uid=0 auid=4294967295 
> ses=4294967295 subj==unconfined msg='unit=apache2 comm="systemd" 
> exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
> 
> Seems fine to me.

On the contrary. These show that apache2 binary was denied from reading
/etc/gai.conf *and* /etc/apache2/apache2.conf by some Mandatory Access
Control (audit record type AVC).
Since you're using Debian, I suspect AppArmor.

First things first, Apparmor (and any kind of MAC) is a good thing,
especially in your typical server environment. They'll suggest you to
disable it - don't. Lowering overall security of your OS is not worth
it.

Second, Debian does not provide apparmor profiles for apache. Whatever
profile is active in your installation is a result of local
misconfiguration.

Third, it's fixable. Install apparmor-utils.
Invoke 'aa-complain /usr/sbin/apache2'.
Start your apache2 service, stop it and start again.
Make some GET/PUT requests to it.
Invoke 'aa-logprof' and generate Apparmor profile that's uniquely suited
for your environment.
Invoke 'aa-enforce /usr/sbin/apache2', and you're set.

Reco

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Steve Kemp]

  To recap you reported the original error:

>  apache2: Could not open configuration file /etc/apache2/apache2.conf:
>  Permission denied

  Now you've provided more details, from your audit-log:

> type=AVC msg=audit(1539750555.347:77): apparmor="DENIED"
> operation="open" profile="/usr/sbin/apache2"
> name="/etc/apache2/apache2.conf" pid=17485 comm="apache2"
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  There you see "DENIED" along with "exit=-13".  You can lookup
 the meaning of "-13" via this command but I'll guess it correpondes to
 EPERM ("permission denied"):

ausearch --interpret --exit -13

  In conclusion: You're using apparmor, it prevented the process from
 opening the configuration file, which stopped the service from starting.
 That was logged explicitly :)

  To fix this either:

1.  Fix apparmor so that you can open the file.

2.  Disable apparmor.

  The first might be as simple as `systemctl restart apparmor.service`,
 that's working on the basis that:

* You had apparmor installed.
* You've now just installed apache.
* This will have given you new apparmor rules.
* But they won't be loaded because apparmor wasn't reloaded.
* So apache failed.

  I'm not 100% sure if that is the case, but it seems likely.  If not
 you'll need to do some reading.  Perhaps start here:

https://wiki.debian.org/AppArmor

Steve
-- 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Le 16-10-2018, à 06:39:01 +, Steve Kemp a écrit :



ls -l /etc/apache2/apache2.conf
-rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf


Getting nuts.


 Probably the permissions on /etc/apache2, or /etc are broken for the
user www-data.


ls -l /etc
drwxr-xr-x 213 root  root  16384 oct 17 06:28

ls -l /etc/apache2
total 80
-rw-r--r-- 1 root root  7224 jun  2 10:01 apache2.conf
drwxr-xr-x 2 root root  4096 oct 16 06:56 conf-available
drwxr-xr-x 2 root root  4096 oct 16 06:57 conf-enabled
-rw-r--r-- 1 root root  1782 avr  5  2018 envvars
-rw-r--r-- 1 root root 31063 sep 19  2017 magic
drwxr-xr-x 2 root root 12288 oct 16 06:57 mods-available
drwxr-xr-x 2 root root  4096 oct 16 06:57 mods-enabled
-rw-r--r-- 1 root root   320 sep 19  2017 ports.conf
drwxr-xr-x 2 root root  4096 oct 16 06:57 sites-available
drwxr-xr-x 2 root root  4096 oct 16 06:57 sites-enabled




 Assuming you have sudo installed you can become "www-data", and test:

   sudo su - www-data -s /bin/sh
   cd /etc/
   cd apache2
   cat apache2.conf


All fine, www-data can read the file.

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Le 16-10-2018, à 09:51:22 +0300, Reco a écrit :


Hi.

On Tue, Oct 16, 2018 at 07:31:17AM +0200, steve wrote:

Hi there,

Purged and then reinstalled apache2 and when I want to start apache2,
here's what I get:

# systemctl status apache2.service
● apache2.service - The Apache HTTP Server
  Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: 
enabled)
  Active: failed (Result: exit-code) since Tue 2018-10-16 07:22:02 CEST; 13s ago
 Process: 32122 ExecStart=/usr/sbin/apachectl start (code=exited, 
status=1/FAILURE)

oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
oct 16 07:22:01 box apachectl[32122]: apache2: Could not open configuration 
file /etc/apache2/apache2.conf: Permission denied
oct 16 07:22:02 box apachectl[32122]: Action 'start' failed.
oct 16 07:22:02 box apachectl[32122]: The Apache error log may have more 
information.


So, does the 'Apache error log' have anything useful?


Nothing. It's empty.



ls -l /etc/apache2/apache2.conf
-rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf


First things first, it's 'ls -lZ /etc/apache2/apache2.conf'.


# ls -lZ /etc/apache2/apache2.conf 
-rw-r--r-- 1 root root ? 7224 jun  2 10:01 /etc/apache2/apache2.conf



Next thing to check is 'ls -ald / /etc /etc/apache2'.


# ls -ald /etc/apache2
drwxr-xr-x 8 root root 4096 oct 16 07:21 /etc/apache2


And, finally, /var/log/audit/audit.log if you have auditd installed
(hint - install it if you don't).


grep apache /var/log/audit/audit.log

type=AVC msg=audit(1539750555.347:76): apparmor="DENIED" operation="open" profile="/usr/sbin/apache2" 
name="/etc/gai.conf" pid=17485 comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
type=SYSCALL msg=audit(1539750555.347:76): arch=c03e syscall=2 success=no exit=-13 
a0=7fe220cac22a a1=8 a2=1b6 a3=8 items=0 ppid=17482 pid=17485 auid=4294967295 uid=0 gid=0 
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apache2" 
exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) key=(null)
type=AVC msg=audit(1539750555.347:77): apparmor="DENIED" operation="open" profile="/usr/sbin/apache2" 
name="/etc/apache2/apache2.conf" pid=17485 comm="apache2" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
type=SYSCALL msg=audit(1539750555.347:77): arch=c03e syscall=2 success=no exit=-13 
a0=7fe2219b6f70 a1=8 a2=1b6 a3=ff7f items=0 ppid=17482 pid=17485 auid=4294967295 
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 
comm="apache2" exe="/usr/sbin/apache2" subj==/usr/sbin/apache2 (enforce) 
key=(null)
type=SERVICE_START msg=audit(1539750555.383:78): pid=1 uid=0 auid=4294967295 ses=4294967295 
subj==unconfined msg='unit=apache2 comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=failed'


Seems fine to me.


Steve

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[David Wright]

On Tue 16 Oct 2018 at 12:24:49 (-0400), Gene Heskett wrote:
> On Tuesday 16 October 2018 11:37:44 Greg Wooledge wrote:
> 
> > On Tue, Oct 16, 2018 at 11:28:44AM -0400, Gene Heskett wrote:
> > > Since leaving a sudo -i laying about is considered a security
> > > breach, I'm amazed that the -i option doesn't accept a timeout. Say
> > > in seconds, as if you think it will take 5 minutes to do the job as
> > > root, sudo -i300, at the ends of which it expires.
> >
> > You could set the TMOUT variable in the resulting shell, either
> > manually or by a setting in some rc file (e.g. /root/.bashrc if that's
> > what the shell reads).
> 
> Okayyy, TMOUT=30, and 30 seconds later it does time out, returning me to 
> my user prompt.
> 
> And I ran synaptic and it didn't time out till 30 secs after I had quit 
> synaptic which leaves an exploitable hole. Synaptic took way more, than 
> the 30 I set TMOUT to.  Ideally it should have returned to the users 
> prompt at the synaptic exit, or would that leave trash behind?
> 
> Anyway, many thanks for the schooling, Greg. Even after 20 years, I 
> hadn't heard of that before.

Hm, to be honest, TMOUT seems like a historical relic of a bygone era
when using an idle login shell implied that you were hogging a slot
that others were waiting to access. (And when the shell exited, we
neighbouring users would have to endure the motor noise of their
A/KSR 33 until *its* timeout expired.)

If you want a suicidal command that logs you out as soon as you quit,
you could wrap it up as a bash function and put it into root's .bashrc;
something like for example

function aptitude-pop {
aptitude
exit
}

Cheers,
David.

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Gene Heskett]

On Tuesday 16 October 2018 11:37:44 Greg Wooledge wrote:

> On Tue, Oct 16, 2018 at 11:28:44AM -0400, Gene Heskett wrote:
> > Since leaving a sudo -i laying about is considered a security
> > breach, I'm amazed that the -i option doesn't accept a timeout. Say
> > in seconds, as if you think it will take 5 minutes to do the job as
> > root, sudo -i300, at the ends of which it expires.
>
> You could set the TMOUT variable in the resulting shell, either
> manually or by a setting in some rc file (e.g. /root/.bashrc if that's
> what the shell reads).

Okayyy, TMOUT=30, and 30 seconds later it does time out, returning me to 
my user prompt.

And I ran synaptic and it didn't time out till 30 secs after I had quit 
synaptic which leaves an exploitable hole. Synaptic took way more, than 
the 30 I set TMOUT to.  Ideally it should have returned to the users 
prompt at the synaptic exit, or would that leave trash behind?

Anyway, many thanks for the schooling, Greg. Even after 20 years, I 
hadn't heard of that before.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Gene Heskett]

On Tuesday 16 October 2018 11:37:44 Greg Wooledge wrote:

> On Tue, Oct 16, 2018 at 11:28:44AM -0400, Gene Heskett wrote:
> > Since leaving a sudo -i laying about is considered a security
> > breach, I'm amazed that the -i option doesn't accept a timeout. Say
> > in seconds, as if you think it will take 5 minutes to do the job as
> > root, sudo -i300, at the ends of which it expires.
>
> You could set the TMOUT variable in the resulting shell, either
> manually or by a setting in some rc file (e.g. /root/.bashrc if that's
> what the shell reads).

This would be about as handy as a 2x2 alongside the ear, by making it 
automatic but fixed. On this machine, 10 minutes is a great plenty to 
run synaptic, but on the pi, 20 minutes or more would be needed. So 
whats wrong with the sudo timeout being set at the launch time?  And 
sitting here thinking, thats not a bad idea as you could set a shorter 
time than it takes to do whatever, in the meantime its timed out, so 
whenever that utility gets done, the su has long since timed out, 
leaving no exposure when whatever was launched with root priv's keeps on 
doing what it does. Best of both IMO.

Something to consider, Greg, and thank you.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Greg Wooledge]

On Tue, Oct 16, 2018 at 11:28:44AM -0400, Gene Heskett wrote:
> Since leaving a sudo -i laying about is considered a security breach, I'm 
> amazed that the -i option doesn't accept a timeout. Say in seconds, as 
> if you think it will take 5 minutes to do the job as root, sudo -i300, 
> at the ends of which it expires.

You could set the TMOUT variable in the resulting shell, either manually
or by a setting in some rc file (e.g. /root/.bashrc if that's what the
shell reads).

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Gene Heskett]

On Tuesday 16 October 2018 05:56:31 Jonathan Dowland wrote:

> On Tue, Oct 16, 2018 at 10:09:39AM +0200, Martin wrote:
> >> sudo su - www-data -s /bin/sh
> >
> >Don't use sudo with su. It is evil.
> >You want to use 'sudo -i' in this case.
>
> Fascism is evil. This is just unnecessary.
>
> (I'm guilty of still typing "sudo su -" via muscle memory even after
> your messages on the subject. I asked a former UNIX sysadmin colleague
> of mine and he does the same. We suspect that it was from our days
> supporting Solaris, and a sudo that did not implement -i.)

Since leaving a sudo -i laying about is considered a security breach, I'm 
amazed that the -i option doesn't accept a timeout. Say in seconds, as 
if you think it will take 5 minutes to do the job as root, sudo -i300, 
at the ends of which it expires.  That makes more sense than 
the "-i"less 1/2 minute of inactivity to me. At least the exposure is 
limited to less time than it takes to refill your caffeine container and 
catch up on the gossip at the water fountain. ;-)

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Martin]

Am 16.10.18 um 11:56 schrieb Jonathan Dowland:
> On Tue, Oct 16, 2018 at 10:09:39AM +0200, Martin wrote:
>>>     sudo su - www-data -s /bin/sh
>>
>> Don't use sudo with su. It is evil.
>> You want to use 'sudo -i' in this case.
> 
> Fascism is evil. This is just unnecessary.

Good point.

> 
> (I'm guilty of still typing "sudo su -" via muscle memory even after
> your messages on the subject. I asked a former UNIX sysadmin colleague
> of mine and he does the same. We suspect that it was from our days
> supporting Solaris, and a sudo that did not implement -i.)

I know. And if I do right, it was not even officially available for Solaris. It 
came from this Sunfreeware site. Which still exists with a sudo version from 
2014.

Cheers on that, old man!!

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Jonathan Dowland]

On Tue, Oct 16, 2018 at 10:09:39AM +0200, Martin wrote:

sudo su - www-data -s /bin/sh


Don't use sudo with su. It is evil.
You want to use 'sudo -i' in this case.


Fascism is evil. This is just unnecessary.

(I'm guilty of still typing "sudo su -" via muscle memory even after
your messages on the subject. I asked a former UNIX sysadmin colleague
of mine and he does the same. We suspect that it was from our days
supporting Solaris, and a sudo that did not implement -i.)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Joe]

On Tue, 16 Oct 2018 10:06:39 +0200
Martin  wrote:

> Am 16.10.18 um 07:31 schrieb steve:
> > Hi there,
> > 
> > Purged and then reinstalled apache2 and when I want to start
> > apache2, here's what I get:
> > 
> > # systemctl status apache2.service  
> 
> What is your 'id'?
> 
> > ● apache2.service - The Apache HTTP Server
> >   Loaded: loaded (/lib/systemd/system/apache2.service; enabled;
> > vendor preset: enabled) Active: failed (Result: exit-code) since
> > Tue 2018-10-16 07:22:02 CEST; 13s ago Process: 32122
> > ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
> > 
> > oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
> > oct 16 07:22:01 box apachectl[32122]: apache2: Could not open
> > configuration file /etc/apache2/apache2.conf: Permission denied oct
> > 16 07:22:02 box apachectl[32122]: Action 'start' failed. oct 16
> > 07:22:02 box apachectl[32122]: The Apache error log may have more
> > information. oct 16 07:22:02 box systemd[1]: apache2.service:
> > Control process exited, code=exited status=1 oct 16 07:22:02 box
> > systemd[1]: apache2.service: Failed with result 'exit-code'. oct 16
> > 07:22:02 box systemd[1]: Failed to start The Apache HTTP Server.  
> 
> Do you have any SSLCertificateKeyFile configured? Check permissions
> first, as a normal user can not read those. 
> > 
> > ls -l /etc/apache2/apache2.conf
> > -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf

Surely apache2 starts up as root, in order to obtain port 80, and then
drops privilege to www-data? It must read the configuration files while
root, or else it wouldn't know which port(s) it should request.

-- 
Joe

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Martin]

Am 16.10.18 um 08:39 schrieb Steve Kemp:
>>
>> ls -l /etc/apache2/apache2.conf
>> -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf
[...]
> sudo su - www-data -s /bin/sh

Don't use sudo with su. It is evil.
You want to use 'sudo -i' in this case.

[...]

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Martin]

Am 16.10.18 um 07:31 schrieb steve:
> Hi there,
> 
> Purged and then reinstalled apache2 and when I want to start apache2,
> here's what I get:
> 
> # systemctl status apache2.service

What is your 'id'?

> ● apache2.service - The Apache HTTP Server
>   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
> preset: enabled)
>   Active: failed (Result: exit-code) since Tue 2018-10-16 07:22:02 CEST; 13s 
> ago
>  Process: 32122 ExecStart=/usr/sbin/apachectl start (code=exited, 
> status=1/FAILURE)
> 
> oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
> oct 16 07:22:01 box apachectl[32122]: apache2: Could not open configuration 
> file /etc/apache2/apache2.conf: Permission denied
> oct 16 07:22:02 box apachectl[32122]: Action 'start' failed.
> oct 16 07:22:02 box apachectl[32122]: The Apache error log may have more 
> information.
> oct 16 07:22:02 box systemd[1]: apache2.service: Control process exited, 
> code=exited status=1
> oct 16 07:22:02 box systemd[1]: apache2.service: Failed with result 
> 'exit-code'.
> oct 16 07:22:02 box systemd[1]: Failed to start The Apache HTTP Server.

Do you have any SSLCertificateKeyFile configured? Check permissions first, as a 
normal user can not read those.
 
> 
> ls -l /etc/apache2/apache2.conf
> -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf
> 
> 
> Getting nuts.
> 
> Any ideas?
> 
> Thanks
> 

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Reco]

Hi.

On Tue, Oct 16, 2018 at 07:31:17AM +0200, steve wrote:
> Hi there,
> 
> Purged and then reinstalled apache2 and when I want to start apache2,
> here's what I get:
> 
> # systemctl status apache2.service
> ● apache2.service - The Apache HTTP Server
>   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
> preset: enabled)
>   Active: failed (Result: exit-code) since Tue 2018-10-16 07:22:02 CEST; 13s 
> ago
>  Process: 32122 ExecStart=/usr/sbin/apachectl start (code=exited, 
> status=1/FAILURE)
> 
> oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
> oct 16 07:22:01 box apachectl[32122]: apache2: Could not open configuration 
> file /etc/apache2/apache2.conf: Permission denied
> oct 16 07:22:02 box apachectl[32122]: Action 'start' failed.
> oct 16 07:22:02 box apachectl[32122]: The Apache error log may have more 
> information.

So, does the 'Apache error log' have anything useful?

> ls -l /etc/apache2/apache2.conf
> -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf

First things first, it's 'ls -lZ /etc/apache2/apache2.conf'.
Next thing to check is 'ls -ald / /etc /etc/apache2'.
And, finally, /var/log/audit/audit.log if you have auditd installed
(hint - install it if you don't).

Reco

Re: apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[Steve Kemp]

> 
> ls -l /etc/apache2/apache2.conf
> -rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf
> 
> 
> Getting nuts.

  Probably the permissions on /etc/apache2, or /etc are broken for the
 user www-data.

  Assuming you have sudo installed you can become "www-data", and test:

sudo su - www-data -s /bin/sh
cd /etc/
cd apache2
cat apache2.conf

Steve
-- 

apache2: Could not open configuration file /etc/apache2/apache2.conf: Permission denied

[steve]

Hi there,

Purged and then reinstalled apache2 and when I want to start apache2,
here's what I get:

# systemctl status apache2.service
● apache2.service - The Apache HTTP Server
  Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: 
enabled)
  Active: failed (Result: exit-code) since Tue 2018-10-16 07:22:02 CEST; 13s ago
 Process: 32122 ExecStart=/usr/sbin/apachectl start (code=exited, 
status=1/FAILURE)

oct 16 07:22:01 box systemd[1]: Starting The Apache HTTP Server...
oct 16 07:22:01 box apachectl[32122]: apache2: Could not open configuration 
file /etc/apache2/apache2.conf: Permission denied
oct 16 07:22:02 box apachectl[32122]: Action 'start' failed.
oct 16 07:22:02 box apachectl[32122]: The Apache error log may have more 
information.
oct 16 07:22:02 box systemd[1]: apache2.service: Control process exited, 
code=exited status=1
oct 16 07:22:02 box systemd[1]: apache2.service: Failed with result 'exit-code'.
oct 16 07:22:02 box systemd[1]: Failed to start The Apache HTTP Server.


ls -l /etc/apache2/apache2.conf
-rw-r--r-- 1 root root 7224 jun  2 10:01 /etc/apache2/apache2.conf


Getting nuts.

Any ideas?

Thanks

Re: '/proc/sys/kernel/core_pattern': Permission denied

[Sven Joachim]

On 2017-10-04 23:22 +0200, Uwe Mintermann wrote:

> I am facing the problem that no core files are written on my server
> (Debian GNU/Linux buster/sid).
>
> root:~# sysctl kernel.core_pattern
> kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
> root:~# ls /usr/libexec/abrt-hook-ccpp
> ls: cannot access '/usr/libexec/abrt-hook-ccpp': No such file or directory
>
> Ok problem is clear. abrt should handle segment faults but abrt is not
> installed. So I am trying to change the sysctl kernel.core_pattern to
> "core" as root (no sudo).
>
> root:~# sysctl -w kernel.core_pattern=core
> sysctl: permission denied on key 'kernel.core_pattern'
>
>
> root:~# echo "core" > /proc/sys/kernel/core_pattern
> bash: /proc/sys/kernel/core_pattern: Permission denied
>
> root:~# rm /proc/sys/kernel/core_pattern
> rm: cannot remove '/proc/sys/kernel/core_pattern': Permission denied
>
> Whats wrong? I have no access as root even though the file system is
> mounted as writable.

Does your server run in a container?  I found a few links which indicate
that this might lead to the problem[1,2].

Cheers,
   Sven


1. https://forum.proxmox.com/threads/php-fpm-core-dumps-how-to-enable.30868/
2. 
http://forum.odin.com/threads/proc-sys-kernel-core_pattern-permission-denied.338549/

'/proc/sys/kernel/core_pattern': Permission denied

[Uwe Mintermann]

Hi,

I am facing the problem that no core files are written on my server
(Debian GNU/Linux buster/sid).

root:~# sysctl kernel.core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
root:~# ls /usr/libexec/abrt-hook-ccpp
ls: cannot access '/usr/libexec/abrt-hook-ccpp': No such file or directory

Ok problem is clear. abrt should handle segment faults but abrt is not
installed. So I am trying to change the sysctl kernel.core_pattern to
"core" as root (no sudo).

root:~# sysctl -w kernel.core_pattern=core
sysctl: permission denied on key 'kernel.core_pattern'


root:~# echo "core" > /proc/sys/kernel/core_pattern
bash: /proc/sys/kernel/core_pattern: Permission denied

root:~# rm /proc/sys/kernel/core_pattern
rm: cannot remove '/proc/sys/kernel/core_pattern': Permission denied

Whats wrong? I have no access as root even though the file system is
mounted as writable.

-rw-r--r-- 1 root root 0 Oct  3 21:01 /proc/sys/kernel/core_pattern
proc on /proc type proc (rw,relatime)


Can anyone help? I have installed some debian testing packages a few
months ago and reverted it.

Thanks!
Uwe

Re: usb permission denied

[davidson]

On Tue, 27 Sep 2016, Ric Moore wrote:


libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/001/006: Permission denied.

If anyone can assist, I'd love to fix this. Ric


You know the drill.

For posterity's sake, can you provide more context?

What are you doing, that triggers these messages? (NB: If it involves
scanning vintage pornographic magazines, you can probably leave out
the "pornographic" bit. Nobody here needs to know.)

And, aside from the messages, what unexpected behavior accompanies
them?

usb permission denied

[Ric Moore]

libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/001/006: Permission denied.

If anyone can assist, I'd love to fix this. Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: NFS no_root_squash not working (permission denied)

[Greg Wooledge]

On Thu, Aug 11, 2016 at 05:43:12PM +0200, Ulf Volmer wrote:
> /etc/exports is
> 
> /export/backup-n40l   bob.clients(rw,no_subtree_check)
> virt(rw,no_root_squash,no_subtree_check)

I changed my /etc/exports from what I had to:

/home   arc1(ro,no_root_squash,sync,no_subtree_check)

Ran exportfs -a, and IT WORKED.

Thank you, Ulf.  None of the rest of this is directed at you.

Holy crap.  That means I have to put no_subtree_check in EVERY DAMNED
FIELD of EVERY DAMNED LINE :-(

Why...?!

Why isn't there any way to tell /etc/exports "I want to add these two
options to EVERY SINGLE FIELD of EVERY SINGLE LINE without having to
type it out a couple hundred times"?

The one option we had that allowed us to write it once per LINE instead
of once per FIELD is now BROKEN?!

Well, I guess I have additional information to add in the bug report.

Re: NFS no_root_squash not working (permission denied)

[Ulf Volmer]

On 08/10/2016 11:17 PM, Greg Wooledge wrote:

> Any suggestions on what I can try to change?  Could you post your jessie
> server's /etc/exports and /etc/default/nfs-kernel-server configs, or at
> least the parts relevant to the working no_root_squash mount?  And any
> other configs that I don't know about
> 
> Which kernel version?  Just in case this is a kernel issue.

latest jessie kernel (3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt25-2+deb8u3), no changes in /etc/default/nfs-kernel-server
configs.

/etc/exports is

/export/backup-n40l bob.clients(rw,no_subtree_check)
virt(rw,no_root_squash,no_subtree_check)

best regards
Ulf

Re: NFS no_root_squash not working (permission denied)

[Greg Wooledge]

On Wed, Aug 10, 2016 at 05:17:32PM -0400, Greg Wooledge wrote:
> Any suggestions on what I can try to change?  Could you post your jessie
> server's /etc/exports and /etc/default/nfs-kernel-server configs, or at
> least the parts relevant to the working no_root_squash mount?  And any
> other configs that I don't know about
> 
> Which kernel version?  Just in case this is a kernel issue.

Additional information: installing and rebooting into the jessie-backports
kernel (linux-image-4.6.0-0.bpo.1-amd64) did not change anything.
Still permission denied.

I am still open to any and all suggestions.

(To be more precise: on my desktop machine, I returned
/etc/default/nfs-kernel-server to its default state; tried again;
rebooted; tried again; installed the backport kernel, rebooted; tried
again; disabled NFSv4 in /etc/default/n-k-s; restarted nfs-common and
nfs-kernel-server services; tried again.  Everything I have tried so
far has failed with Permission denied.)

Re: NFS no_root_squash not working (permission denied)

[Greg Wooledge]

On Wed, Aug 10, 2016 at 11:01:41PM +0200, Erwan David wrote:
> Le 10/08/2016 à 22:38, Ulf Volmer a écrit :
> >> Is there ANYONE using NFS with no_root_squash on jessie amd64 successfully?
> >> If so, please tell me how you did it!
> > NFS run here with jessie amd64 and no_root_squash fine w/o any problems.
> >
> > Server is jessie, client is centos/fedora. There must something wrong on
> > your setup.

Any suggestions on what I can try to change?  Could you post your jessie
server's /etc/exports and /etc/default/nfs-kernel-server configs, or at
least the parts relevant to the working no_root_squash mount?  And any
other configs that I don't know about

Which kernel version?  Just in case this is a kernel issue.

> I've seen some problems with a mix of NFS v3 and v4. Especially if v4 is
> enabled but not fully configured.

I googled "debian disable nfsv4".  It came up with
http://unix.stackexchange.com/questions/205403/disable-nfsv4-server-on-debian-allow-nfsv3

I edited /etc/default/nfs-kernel-server as indicated in the answers,
adding "--no-nfs-version 4" to *TWO* places.  Restarted nfs-kernel-server.
Mounted from the client.  Still permission denied.  Re-ran "exportfs -a"
on the server.  Re-mounted from the client.  Still permission denied.

(All of this on my desktop "server" of course, not the real server.)

Re: NFS no_root_squash not working (permission denied)

[Erwan David]

Le 10/08/2016 à 22:38, Ulf Volmer a écrit :
>> Is there ANYONE using NFS with no_root_squash on jessie amd64 successfully?
>> If so, please tell me how you did it!
> NFS run here with jessie amd64 and no_root_squash fine w/o any problems.
>
> Server is jessie, client is centos/fedora. There must something wrong on
> your setup.
>
> best regards
> Ulf
>
>
I've seen some problems with a mix of NFS v3 and v4. Especially if v4 is
enabled but not fully configured.

Re: NFS no_root_squash not working (permission denied)

[Ulf Volmer]

> Is there ANYONE using NFS with no_root_squash on jessie amd64 successfully?
> If so, please tell me how you did it!

NFS run here with jessie amd64 and no_root_squash fine w/o any problems.

Server is jessie, client is centos/fedora. There must something wrong on
your setup.

best regards
Ulf

Re: NFS no_root_squash not working (permission denied)

[Greg Wooledge]

On Tue, Aug 09, 2016 at 09:14:56AM -0400, Greg Wooledge wrote:
> On Mon, Aug 08, 2016 at 11:14:36AM -0400, Greg Wooledge wrote:
> > It appears that no_root_squash is being ignored.

Opened bug #833925. :(

Re: NFS no_root_squash not working (permission denied)

[Greg Wooledge]

On Mon, Aug 08, 2016 at 11:14:36AM -0400, Greg Wooledge wrote:
> It appears that no_root_squash is being ignored.
> 
> 1) NFS server: svr4 (jessie)
> 
> /home   -no_subtree_check arc1(ro,no_root_squash,sync)

Nobody? :(

Additional information:

 * It's not limited to /home.  Other exported directories that should
   be no_root_squash'ed are in fact squashed.

 * It's not limited to the squeeze client arc1.  Mounting from another
   client (jessie) still shows the problem.

 * The previous machine where it worked was i386.  The current machine
   where it's *not* working is amd64.

 * I have another jessie i386 server where no_root_squash works fine.

 * If I install nfs-kernel-server on my jessie amd64 desktop PC and
   configure /home for export (exactly the same config as above) and
   do "sudo systemctl restart nfs-kernel-server.service" to get rpc.mountd
   to run, it fails just like svr4.

My conclusion at this point is no_root_squash is completely broken on
jessie amd64, at least in the default configuration.  It works on
jessie i386.

Is there ANYONE using NFS with no_root_squash on jessie amd64 successfully?
If so, please tell me how you did it!

NFS no_root_squash not working (permission denied)

[Greg Wooledge]

I am trying to backup files from one server, using another server
which has a tape drive attached.  I've done this many times before.
The problem is, *this* time, root on the NFS client can't read the files
on the NFS server.  It appears that no_root_squash is being ignored.

I have two Debian systems:

1) NFS server: svr4 (jessie)
2) NFS client: arc1 (squeeze) (has tape drive)

On the server (svr4) I have this line in /etc/exports:

/home   -no_subtree_check arc1(ro,no_root_squash,sync)

On the client I use autofs, but for purposes of demonstrating the problem
I will use manual mount commands.  (Rest assured it breaks just the same
with autofs mounts.)

arc1:~# mount -v -t nfs svr4:/home /mnt
mount.nfs: timeout set for Mon Aug  8 10:57:37 2016
mount.nfs: trying text-based options 'addr=10.76.142.85'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: trying 10.76.142.85 prog 13 vers 3 prot TCP port 2049
mount.nfs: prog 15, trying vers=3, prot=17
mount.nfs: trying 10.76.142.85 prog 15 vers 3 prot UDP port 58163
svr4:/home on /mnt type nfs (rw)
arc1:~# ls /mnt/wooledg/Maildir
ls: cannot open directory /mnt/wooledg/Maildir: Permission denied
arc1:~# su wooledg -c 'ls /mnt/wooledg/Maildir'
courierimapkeywords  courierimapuiddb  cur  new  tmp
arc1:~# umount /mnt

arc1:~# showmount -e svr4 | grep /home
/home  arc1.eeg.ccf.org

So, the file system mounts correctly, and the non-root user can read
the files, but root can't read them.

I have rebooted both the client and server machines.  I have tried
restarting NFS services on them, too.  I have done "exportfs -u -a" and
"exportfs -a".  I've done everything I can think of.

This is very similar to what I see in bug #492970 and this past
discussion:

https://lists.debian.org/debian-user/2008/08/msg01943.html
http://bugs.debian.org/492970

However, both of my systems are newer than the systems described in
that bug report, and I don't think "downgrade to nfs-common 1.1.2"
is a viable solution for me.

Is there any package I might be missing on the new jessie server, either
for general NFS operations, or specifically for compatibility with older
Linux NFS clients?

root@svr4:/# uname -a
Linux svr4 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) 
x86_64 GNU/Linux
root@svr4:/# dpkg -l | grep -E 'nfs|portmap|rpcbind'
ii  libnfsidmap2:amd64 0.25-5 amd64 
   NFS idmapping library
ii  nfs-common 1:1.2.8-9  amd64 
   NFS support files common to client and server
ii  nfs-kernel-server  1:1.2.8-9  amd64 
   support for NFS kernel server
rc  portmap6.0.0-2amd64 
   RPC port mapper
ii  rpcbind0.2.1-6+deb8u1 amd64 
   converts RPC program numbers into universal addresses

arc1:~# uname -a
Linux arc1 2.6.28-1-amd64 #1 SMP Wed Feb 18 17:16:12 UTC 2009 x86_64 GNU/Linux
arc1:~# dpkg -l | grep -E 'nfs|portmap|rpcbind'
ii  libnfsidmap20.23-2   An nfs 
idmapping library
ii  nfs-common  1:1.2.2-4squeeze3NFS 
support files common to client and server
ii  nfs-kernel-server   1:1.2.2-4squeeze3support 
for NFS kernel server
ii  portmap 6.0.0-2  RPC port 
mapper

root@svr4:/# tail /var/log/daemon.log
...
Aug  8 10:55:37 svr4 rpc.mountd[1312]: authenticated mount request from 
arc1.eeg.ccf.org:823 for /home (/home)
Aug  8 10:56:05 svr4 rpc.mountd[1312]: authenticated unmount request from 
arc1.eeg.ccf.org:809 for /home (/home)
...

One final note, though I don't know how it may relate: svr4 was just
upgraded to Jessie on Friday, to replace a machine that died.  I reused
the same IP address.  The machine that died was running Jessie but with
a Wheezy kernel; it had been upgraded many times, originally installed
from Lenny IIRC.  This all worked fine on the old server.  It is not
working on the new server.  It had crossed my mind that something was
caching the old server's information due to the IP address reuse, but
I have rebooted both systems since then, so that shouldn't be the case.

Re: Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Rick Thomas]

On Dec 30, 2015, at 3:36 AM, Steffen Nurpmeso  wrote:

> Hello!
> 
> Rick Thomas  wrote:
> |Hi Steffan,
> 
> (My name is Steffen)

Ooops!  Sorry!

> Well, just as already shown in this thread, on my local box it is
> 
>  ?0[sdaoden@wales nail.git]$ ll /usr/local/libexec/s-nail-privsep
>  -r-sr-xr-x 1 root root 9860 Dec  2 14:45 /usr/local/libexec/s-nail-privsep*
> 
> It must be SETUID to a super-user that can impersonate as all
> users and groups that mailx(1) may potentially open system
> mailboxes for in order to give mailbox locks the UID and GID of
> the mailbox they are ment for.  Usually only root satisfies this.
> I thing i need to improve the wording (not examples) in make.rc
> and INSTALL.

So the fix posted by Hilko Bengen is correct.  Thanks for the confirmation!

> 
> |Thanks for all your help!
> 
> Hm.  Thanks to you.  Just complain loudly if something isn't what
> you’d expected!

Don’t worry, I will!

> Ciao,
> 
> |Rick
> 
> --steffen
> 

Re: Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Jörg-Volker Peetz]

Steffen Nurpmeso wrote on 12/30/15 12:36:
> Hello!
> 
> Rick Thomas  wrote:


>  |-rwxr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep

Wouldn't these be enough rights for mailx to do it's work?
I.e., owner: root, group: mail, sticky bit for the group?
This works on my system (and on Rick's).

Regards,
jvp.

Re: Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Rick Thomas]

On Dec 30, 2015, at 9:51 AM, Jörg-Volker Peetz  wrote:

> Steffen Nurpmeso wrote on 12/30/15 12:36:
>> Hello!
>> 
>> Rick Thomas  wrote:
> 
> 
>> |-rwxr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
> 
> Wouldn't these be enough rights for mailx to do it's work?
> I.e., owner: root, group: mail, sticky bit for the group?
> This works on my system (and on Rick's).
> 
> Regards,
> jvp.

Set-gid alone works for all my use cases, but I have never needed to use the 
“-u user” option to masquerade as someone different from myself.  If you need 
to do that, I’m guessing that nothing less than set-uid will do the job.  
Though I haven’t tried it so I don’t know for sure…

Enjoy!
Rick

Re: Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Rick Thomas  wrote:
 |On Dec 30, 2015, at 3:36 AM, Steffen Nurpmeso  wrote:
 |> Rick Thomas  wrote:
 |>|Hi Steffan,
 |> 
 |> (My name is Steffen)
 |
 |Ooops!  Sorry!

Don't worry, i had so many typos myself in what followed..

 ..
 |> It must be SETUID to a super-user that can impersonate as all

 |So the fix posted by Hilko Bengen is correct.  Thanks for the confirmation!

The Debian package system is quite complicated, but if chmod(1)
must be called explicitly then it is, yes.  Normally the
`doinstall' / `packager-install' make(1) rules (`install' in
v14.9) should do the right thing (tm) by themselves.
The current v14.8.6 has already learned and explicitly sorts
sources for reproducible-builds.org and alos should also work on
Debian/kFreeBSD out of the box, for example.  More in v14.9 (e.g.,
truly parallelizable build phase).

 |>|Thanks for all your help!
 |> 
 |> Hm.  Thanks to you.  Just complain loudly if something isn't what
 |> you’d expected!
 |
 |Don’t worry, I will!

Yes, please!

And a happy new year..

--steffen

Re: Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Steffen Nurpmeso]

Hello!

Rick Thomas  wrote:
 |Hi Steffan,

(My name is Steffen)

 |So what, exactly, are the correct permissions for s-nail-privsep?
 |
 |Should it be:
 |-rwxr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
 |or:
 |-rwsr-xr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
 |or:
 |-rwsr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
 |
 |Or something else?

Well, just as already shown in this thread, on my local box it is

  ?0[sdaoden@wales nail.git]$ ll /usr/local/libexec/s-nail-privsep
  -r-sr-xr-x 1 root root 9860 Dec  2 14:45 /usr/local/libexec/s-nail-privsep*

It must be SETUID to a super-user that can impersonate as all
users and groups that mailx(1) may potentially open system
mailboxes for in order to give mailbox locks the UID and GID of
the mailbox they are ment for.  Usually only root satisfies this.
I thing i need to improve the wording (not examples) in make.rc
and INSTALL.

 |Thanks for all your help!

Hm.  Thanks to you.  Just complain loudly if something isn't what
you'd expected!
Ciao,

 |Rick

--steffen

Bug#806858 Re: s-nail: mailx: Unable to (dot) lock mailbox, aborting operation: Permission denied

[Rick Thomas]

Hi Steffan,

So what, exactly, are the correct permissions for s-nail-privsep?

Should it be:
-rwxr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
or:
-rwsr-xr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep
or:
-rwsr-sr-x 1 root mail 10104 Dec  4 14:52 /usr/lib/s-nail/s-nail-privsep

Or something else?

Thanks for all your help!
Rick

s-nail fails with "Unable to (dot) lock mailbox, aborting operation: Permission denied"

[Rick Thomas]

With recent Stretch installations the “mail” (or “mailx”) command is satisfied 
by the s-nail package.
As it comes fresh out of the box, s-nail has a problem with dotlock files.  For 
example:

> rbthomas@half:~$ mail
> Creating dotlock for "/var/mail/rbthomas" .
> Unable to (dot) lock mailbox, aborting operation: Permission denied
> Creating dotlock for "/var/mail/rbthomas" .
> Unable to (dot) lock mailbox, aborting operation: Permission denied
> rbthomas@half:~$ 

I don’t know if this is deliberate, or even whether this is the right fix, but 
the error can be made to go away by doing:

> sudo chown root:mail /usr/lib/s-nail/s-nail-privsep
> sudo chmod g+s /usr/lib/s-nail/s-nail-privsep

If the consensus is that it’s a bug, not a feature, I’ll submit a bug report.  
I guess s-nail is the appropriate package?

Enjoy!
Rick

Re: s-nail fails with "Unable to (dot) lock mailbox, aborting operation: Permission denied"

[Rick Thomas]

On Dec 28, 2015, at 2:31 AM, Rick Thomas <rbtho...@pobox.com> wrote:

> With recent Stretch installations the “mail” (or “mailx”) command is 
> satisfied by the s-nail package.
> As it comes fresh out of the box, s-nail has a problem with dotlock files.  
> For example:
> 
>> rbthomas@half:~$ mail
>> Creating dotlock for "/var/mail/rbthomas" .
>> Unable to (dot) lock mailbox, aborting operation: Permission denied
>> Creating dotlock for "/var/mail/rbthomas" .
>> Unable to (dot) lock mailbox, aborting operation: Permission denied
>> rbthomas@half:~$ 
> 
> I don’t know if this is deliberate, or even whether this is the right fix, 
> but the error can be made to go away by doing:
> 
>> sudo chown root:mail /usr/lib/s-nail/s-nail-privsep
>> sudo chmod g+s /usr/lib/s-nail/s-nail-privsep
> 
> If the consensus is that it’s a bug, not a feature, I’ll submit a bug report. 
>  I guess s-nail is the appropriate package?
> 
> Enjoy!
> Rick

Turns out, that this is bug #806858.

Rick

GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Permission denied

[Slavko]

Hi,

after today update of my Debian testing i cannot hibernate, nor
suspend, not reboot, nor halt the system from the regular user XFCE
session with the message:

GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Permission denied

Please, how i can these thing get back? Which permissions are
required/expected now?

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature

Re: webdruid and cron.daily error: Permission denied

[Raf Czlonka]

On Thu, Oct 06, 2011 at 03:30:33PM BST, Csanyi Pal wrote:
 ${WEBDRUID_BIN} -Q -n ${HOSTNAME} -o ${REPORT_ROOT}${NAME}
 ${LOG_DIR}/${NAME}/access.log.1

Initially I thought that your mailer broke the line but after installing
webdruid I noticed that you simply copied it from an example which in
turn had been copied from a bug report email where this line had been
broken by the email client of a person who reported the bug in a first
place. So either append \ at the end of the first line or make one out
of those two.

 When I run /etc/cron.daily/webdruid I get error message:
 /etc/cron.daily# ./webdruid
 ./webdruid: 19: /var/log/apache2/csplbubba/access.log.1: Permission
 denied 

No wonder, you're trying to run the log file - I should have spotted that
earlier.

 How can I solve this problem?

Stop copying things blatantly without understanding what they do ;^)

Regards,
-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007172634.ga2...@linuxstuff.pl

webdruid and cron.daily error: Permission denied

[Csanyi Pal]

Hi,

I'm trying to use webdruid on my apache2 server.

I'm being following the gerasiov.txt in /usr/share/doc/webdruid/examples 
and have /etc/cron.daily/webdruid file:
file
#!/bin/sh
# /etc/cron.daily/webdruid: webdruid daily maintenance script

WEBDRUID_BIN=/usr/bin/webdruid
WEBDRUID_SITELIST=/etc/webdruid/site.list
LOG_DIR=/var/log/apache2
REPORT_ROOT=/var/www/webdruid/

cat $WEBDRUID_SITELIST | while read HOSTNAME NAME;do (
if [ ! -d ${LOG_DIR}/${NAME} ];then exit 1;fi

if [ ! -d ${REPORT_ROOT}${NAME} ];then
mkdir ${REPORT_ROOT}${NAME}
fi

${WEBDRUID_BIN} -Q -n ${HOSTNAME} -o ${REPORT_ROOT}${NAME}
${LOG_DIR}/${NAME}/access.log.1

) done

exit 0
/file

I made directories:
/var/log/apache2/csplbubba/
/var/log/apache2/csplmoodle
/var/log/apache2/csplwordpress

These directories and files access.log.1 have following rights:
/var/log/apache2# ls -l cspl*

csplbubba:
total 0
-rw-r- 1 root adm 0 Oct  6 15:40 access.log.1

csplmoodle:
total 0
-rw-r- 1 root adm 0 Oct  6 15:41 access.log.1

csplwordpress:
total 0
-rw-r- 1 root adm 0 Oct  6 15:41 access.log.1

When I run /etc/cron.daily/webdruid I get error message:
/etc/cron.daily# ./webdruid
./webdruid: 19: /var/log/apache2/csplbubba/access.log.1: Permission
denied 

How can I solve this problem?

-- 
Regards, Pal
http://cspl.me


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k48ii452.fsf@debian-asztal.excito

Re: webdruid and cron.daily error: Permission denied

[Raf Czlonka]

On Thu, Oct 06, 2011 at 03:30:33PM BST, Csanyi Pal wrote:
 When I run /etc/cron.daily/webdruid I get error message:
 /etc/cron.daily# ./webdruid
 ./webdruid: 19: /var/log/apache2/csplbubba/access.log.1: Permission
 denied 
 
 How can I solve this problem?

Who are you running the script as?

-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111006171125.gb7...@linuxstuff.pl

Re: webdruid and cron.daily error: Permission denied

[Csanyi Pal]

Raf Czlonka r...@linuxstuff.pl writes:

 On Thu, Oct 06, 2011 at 03:30:33PM BST, Csanyi Pal wrote:
 When I run /etc/cron.daily/webdruid I get error message:
 /etc/cron.daily# ./webdruid
 ./webdruid: 19: /var/log/apache2/csplbubba/access.log.1: Permission
 denied 
 
 How can I solve this problem?

 Who are you running the script as?

I'm running the script as root.

-- 
Regards, Pal
http://cspl.me


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwj6hqsj.fsf@debian-asztal.excito

Re: webdruid and cron.daily error: Permission denied

[Raf Czlonka]

On Thu, Oct 06, 2011 at 08:18:52PM BST, Csanyi Pal wrote:
 Raf Czlonka r...@linuxstuff.pl writes:
  Who are you running the script as?
 
 I'm running the script as root.

What about the permissions of the folders themselves, you only sent
file permissions?

-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111006194301.ga8...@linuxstuff.pl

Re: webdruid and cron.daily error: Permission denied

[Csanyi Pal]

Raf Czlonka r...@linuxstuff.pl writes:

 On Thu, Oct 06, 2011 at 08:18:52PM BST, Csanyi Pal wrote:
 Raf Czlonka r...@linuxstuff.pl writes:
  Who are you running the script as?
 
 I'm running the script as root.

 What about the permissions of the folders themselves, you only sent
 file permissions?

The folders has the same permissions too:
 # ls -d cspl*
csplbubba  csplmoodle  csplwordpress
root@b2:/var/log/apache2# ls -ld cspl*
drwxr-x--- 2 root adm 4096 Oct  6 15:43 csplbubba
drwxr-x--- 2 root adm 4096 Oct  6 15:43 csplmoodle
drwxr-x--- 2 root adm 4096 Oct  6 15:43 csplwordpress

-- 
Regards, Pal
http://cspl.me


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehyp99ml.fsf@debian-asztal.excito

apache 2 log : creation of executable memory area failed: Permission denied

[Guy Deleeuw]

Bonjour à tous
je tourne lenny + apache2 dans deux vservers sur deux serveurs
différents.
Sur le serveur interne , tout fonctionne normalement
sur le serveur extranet j'ai dans mes logs :

+ /usr/bin/python /var/www/wt/gddbcore/gdods/DocumentConverter.py 
/var/www/users/guy/tmp/temp9.ods /var/www/users/guy/tmp/temp10.xls
creation of executable memory area failed: Permission denied

Il s'agit de la même config et même api sur les deux ververs.
le document xls est bien construit.

J'ai fouillé pendant plus de 5 heures sans trouver réellement de
solutions.

Qqun a déjà rencontré cette erreur ?

Merci d'avance
Guy


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1298805261.2708.22.camel@pc-1000

Re: apache 2 log : creation of executable memory area failed: Permission denied

[Bernard Schoenacker]

Le Sun, 27 Feb 2011 12:14:21 +0100,
Guy Deleeuw g.de_le...@eurofer.be a écrit :

 Bonjour à tous
 je tourne lenny + apache2 dans deux vservers sur deux serveurs
 différents.
 Sur le serveur interne , tout fonctionne normalement
 sur le serveur extranet j'ai dans mes logs :
 
 + /usr/bin/python /var/www/wt/gddbcore/gdods/DocumentConverter.py 
 /var/www/users/guy/tmp/temp9.ods /var/www/users/guy/tmp/temp10.xls
 creation of executable memory area failed: Permission denied
 
 Il s'agit de la même config et même api sur les deux ververs.
 le document xls est bien construit.
 
 J'ai fouillé pendant plus de 5 heures sans trouver réellement de
 solutions.
 
 Qqun a déjà rencontré cette erreur ?
 
 Merci d'avance
 Guy

bonjour,

aller encore une fois, comme c'est dimanche guy a abusé
du pekèt ...

est il possible de comparer certaines position des users
entre les 2 serveurs ?

que donne :

grep 1000 /etc/passwd
ensuite : tree -Csu /var/www/users/guy/

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110227144043.5284db25.bernard.schoenacker_free.fr@hamtaro

Re: apache 2 log : creation of executable memory area failed: Permission denied

[Guy Deleeuw]

Bonjour,
Le dimanche 27 février 2011 à 14:40 +0100, Bernard Schoenacker a écrit :
 Le Sun, 27 Feb 2011 12:14:21 +0100,
 Guy Deleeuw g.de_le...@eurofer.be a écrit :
 

 bonjour,
 
   aller encore une fois, comme c'est dimanche guy a abusé
   du pekèt ...
 
Jaloux va !
   est il possible de comparer certaines position des users
   entre les 2 serveurs ?
 
Inutile car ces users sont le résultat d'une authentification apache, on
tourne donc sous www-data

   que donne :
 
   grep 1000 /etc/passwd
   ensuite : tree -Csu /var/www/users/guy/
enfin pour te faire plaisir :-)
je plaisante, je pense aussi que c'est un problème de droits mais liés a
l'environment de www-data

grep 1000 /etc/passwd
guy:x:1000:1000:guy,,,:/home/guy:/bin/bash

SrvDBExtra:/# tree -Csu /var/www/users/guy/
/var/www/users/guy/
|-- [www-data4096]  Cfg
|   `-- [www-data 179]  gdQuery2.xml
|-- [www-data4096]  gdQuery2
|   |-- [www-data4096]  level1
|   |-- [root   44753]  msBreakDown
|   |-- [www-data   18046]  test.job
|   |-- [www-data5407]  testTinPlateLabel.job
|   |-- [www-data7745]  testdim
|   `-- [www-data   17218]  testnatprod.job
|-- [www-data4096]  gdReport
`-- [www-data   12288]  tmp
|-- [www-data  239403]  1130756576.rpg
|-- [www-data  239403]  184684674.rpg
|-- [www-data  239403]  332280458.rpg
|-- [www-data  239403]  406833981.rpg
`-- [www-data 138]  gdQuery_702696911.xml

a++
Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1298821226.2708.41.camel@pc-1000

Re: Fwd: Bug#614661: exec: 58: /usr: Permission denied

[Boyd Stephen Smith Jr.]

On Wednesday 23 February 2011 01:23:42 Debian_bug_report wrote:
 Well, I can't understand clearly what Sandro want to say, but I think that
 he talks about the package has be defined like reportbug, but I wanted to
 say other.

There is no other in the Debian BTS.  Each bug is attached to a specific 
package.  There are a few pseudo-packages like wnpp, but those are still 
specific.  You can't just say other; if you haven't determined which 
package or pseudo-package to file against, you haven't done enough discovery 
on your issue for it to actually be a bug.  The Debian BTS (really, most bug 
trackers) are not the front-line for user issues.

 So he said that I should use this list...

Which is a good idea.  Many issues Debian users encounter are not bugs in the 
packages.  Instead they are results of misconfiguration, misunderstanding, or 
just plain ignoring what the system already warned them about.

  My problem happen after I did the distro upgrade... I pass 2 months out
  of my
  debian distro, and I used the testing version (Squeeze), but I return
  yesterday
  to my debian distro and the Squeeze becomes stable... so I did the change
  to
  Debian testing again (now called Wheezy)... so I rename all my source
  packages
  like this source.list:
  
  #mirrors oficiais
  deb http://ftp.br.debian.org/debian/ wheezy main contrib non-free
  deb-src http://ftp.br.debian.org/debian/ wheezy main contrib non-free
  
  #mirrors de segurança
  deb http://security.debian.org/ wheezy/updates main contrib non-free
  deb-src http://security.debian.org/ wheezy/updates main contrib non-free
  
  #mirror multimídia
  deb http://ftp.br.debian.org/debian-multimedia/ testing main
  
  So, I went to my Lxterminal and type: sudo aptitude update. After I
  type:
  sudo aptitude safe-upgrade.

What is the output of (aptitude search '~U')?  What is the output of 
(aptitude search '~o')?  Does (apt-get check) run to completion?  None of 
your packages are in a half-configured or unpacked, unconfigured state are 
they?  What about configuration file you shouldn't be using anymore, packages 
that own one or more of those will be shown in (aptitude search '~c').

  I not use any login manager... I do my login in getty and
  after I start my X and window manager (fluxbox). So, when I restart my
  machine
  and try to start my X with the command startx,

I don't use this method, I use KDM.  From what I understand, the X11 server 
needs to run as root otherwise it cannot access the hardware correctly.  
Hopefully, there are other on the list that are using this method of starting 
their X sessions.

  the system returns the
  error:
  xinit: connection to X server lost and after said Wait for X server to
  shut
  down and stayed with prompt flashing again. So, I tried invoke X with
  root
  and
  I had sucess!

Sounds like the X11 server does need root access, to me.

  When I went to the .xsession-errors I saw this error:
  Xsession: X session started for invisiblemanguard at Ter Fev 22 16:36:02 
  BRT
  2011
  exec: 58: /usr: Permission denied
  
  Like the /usr couldn't be acess by a user... only root can... 

Output of (ls -ld /usr) might be helpful here, but I think you might be 
misinterpreting the error message.

  but I not
  change
  any priority of the system... I only updated to wheezy... that's it... 

Yeah, and sometimes upgrades require manual intervention.  Debian tries to 
keep that minimal, but the release notes exist because we can't eliminate it 
entirely.  Any of the issues that will appear in the Wheezy release notes 
would be issues that you (or testing user like you) encounter and document.

  sorry
  for my english... It's not my mother tongue =/ ;)

It's not bad, IMO.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Fwd: Bug#614661: exec: 58: /usr: Permission denied

[Debian_bug_report]

Well, I can't understand clearly what Sandro want to say, but I think that
he talks about the package has be defined like reportbug, but I wanted to
say other. So he said that I should use this list... I can't understand
why exactly... but I'm here... any answers or help? I'm falling here with
parachute...


Forwarded conversation
Subject: Re: Bug#614661: exec: 58: /usr: Permission denied


From: *Sandro Tosi* mo...@debian.org
Date: 2011/2/22
To: Debian_bug_report invisiblemanguard-debianbugrep...@yahoo.com.br,
614661-d...@bugs.debian.org


go ask debian-user@lists.debian.org, reportbug is NOT the place for such
issues.

On Tue, Feb 22, 2011 at 22:29, Debian_bug_report
invisiblemanguard-debianbugrep...@yahoo.com.br wrote:
 Subject: exec: 58: /usr: Permission denied
 Package: reportbug
 Version: 4.12.6
 Severity: important

 Hi!

 My problem happen after I did the distro upgrade... I pass 2 months out of
 my
 debian distro, and I used the testing version (Squeeze), but I return
 yesterday
 to my debian distro and the Squeeze becomes stable... so I did the change
to
 Debian testing again (now called Wheezy)... so I rename all my source
 packages
 like this source.list:

 # deb cdrom:[Debian GNU/Linux 5.0.0 _Lenny_ - Official amd64 CD Binary-1
 20090214-19:11]/ lenny main

 # deb cdrom:[Debian GNU/Linux 5.0.0 _Lenny_ - Official amd64 CD Binary-1
 20090214-19:11]/ lenny main

 #mirrors oficiais
 deb http://ftp.br.debian.org/debian/ wheezy main contrib non-free
 deb-src http://ftp.br.debian.org/debian/ wheezy main contrib non-free

 #mirrors de segurança
 deb http://security.debian.org/ wheezy/updates main contrib non-free
 deb-src http://security.debian.org/ wheezy/updates main contrib non-free

 #destinados para programas que lançam atualizações constantemente
 #deb http://volatile.debian.org/debian-volatile squeeze/volatile main
 #deb-src http://volatile.debian.org/debian-volatile squeeze/volatile main

 #mirror multimídia
 deb http://ftp.br.debian.org/debian-multimedia/ testing main
 #deb http://ftp.debian-unofficial.org/debian testing main contrib non-free

 #mirror wine:
 #deb http://www.lamaresh.net/apt/ squeeze/main


 So, I went to my Lxterminal and type: sudo aptitude update. After I
type:
 sudo aptitude safe-upgrade.

 The system make a download of 839mb of data. Everything was made without
any
 errors reported... I not use any login manager... I do my login in getty
and
 after I start my X and window manager (fluxbox). So, when I restart my
 machine
 and try to start my X with the command startx, the system returns the
 error:
 xinit: connection to X server lost and after said Wait for X server to
 shut
 down and stayed with prompt flashing again. So, I tried invoke X with
root
 and
 I had sucess! When I went to the .xsession-errors I saw this error:

 Xsession: X session started for invisiblemanguard at Ter Fev 22 16:36:02
BRT
 2011
 exec: 58: /usr: Permission denied

 Like the /usr couldn't be acess by a user... only root can... but I not
 change
 any priority of the system... I only updated to wheezy... that's it...
sorry
 for my english... It's not my mother tongue =/ ;)

 Any doubt or question send me a e-mail!

 Health and Sucess!



 -- Package-specific info:
 ** Environment settings:
 INTERFACE=gtk2

 ** /root/.reportbugrc:
 reportbug_version 4.12.6
 mode novice
 ui gtk2
 offline
 realname Debian bug report
 email invisiblemanguard-debianbugrep...@yahoo.com.br
 no-check-uid
 no-cc
 header X-Debbugs-CC: invisiblemanguard-debianbugrep...@yahoo.com.br
 smtphost reportbug.debian.org

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages reportbug depends on:
 ii  apt 0.8.10.3 Advanced front-end for dpkg
 ii  python  2.6.6-3+squeeze5 interactive high-level
 object-orie
 ii  python-reportbug4.12.6   Python modules for
interacting
 wit

 reportbug recommends no packages.

 Versions of packages reportbug suggests:
 pn  debconf-utilsnone  (no description available)
 pn  debsums  none  (no description available)
 pn  dlocate  none  (no description available)
 ii  emacs23-bin-common   23.2+1-7The GNU Emacs editor's
shared,
 arc
 ii  exim44.72-6  metapackage to ease Exim MTA
 (v4)
 ii  exim4-daemon-light [mail-tra 4.72-6  lightweight Exim MTA (v4)
 daemon
 ii  file 5.04-5  Determines file type using
 magic
 ii  gnupg1.4.10-4GNU privacy guard - a free
PGP
 rep
 ii  python-gtk2  2.17.0-4Python bindings for the GTK+
 widge
 pn  python-gtkspell  none  (no description

permission denied

[Jimmi Nielsen]

Hello.

i have a small problems with my debian server.
alle files are permission 644/600 or something, so i can't change anything
on it.
how can i change it back with root login.

i have try but it say  Permission denied
i try to login with SSH but it say permission denied
how can i change this.

Re: permission denied

[Jordon Bedwell]

On 7/26/10 4:35 PM, Jimmi Nielsen wrote:

Hello.

i have a small problems with my debian server.
alle files are permission 644/600 or something, so i can't change anything
on it.
how can i change it back with root login.

i have try but it say  Permission denied
i try to login with SSH but it say permission denied
how can i change this.



The only way to do this would be trough a console, or some companies 
offer the ability to repair permissions [for example server beach has a 
utility for this].  As soon as you login to console and repair the 
permissions [for SSH first and only ~ at first], make sure you the first 
thing you do is block ALL external communications outside of port 80 and 
SSH [or all communications outside at all ~ if you're in a console 
session, stay in console and just lock all communications] as your 
server might have been hacked.  Coming from somebody who does security, 
this is the first thing I would do, lock down SSH so you can't get in 
and fix anything right away. If you can't get to a console, call the 
company that hosts it, and ask them if they can repair SSH for you and 
verify it's integrity (which they should be willing to do at the least) 
and if they can't, I guess you're screwed unless you get physical access.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c4e0c06.6020...@envygeeks.com

Re: Apache2 chroot /dev/null permission denied

[Boyd Stephen Smith Jr.]

On Wednesday 17 March 2010 17:46:34 Knowledge Seeker wrote:
 Even outside of the chroot when I try to echo something and redirect to
  this device I get the same message:
 
 -su: null: Permission Denied

Something mounted with the nodev option?
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: Apache2 chroot /dev/null permission denied

[Wayne]

Knowledge Seeker wrote:

That is the problem.
The permission is set to 666 and the group is root.
But it still don't work.




I don't know know what else to suggest.

Maybe it is time to upgrade to lenny?

Sorry I could not be of more help.

Wayne


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4ba2429e.9060...@gmail.com

Re: Apache2 chroot /dev/null permission denied

[Mike Bird]

On Wed March 17 2010 19:00:35 Knowledge Seeker wrote:
 That is the problem.
 The permission is set to 666 and the group is root.
 But it still don't work.

Please post the exact complete error message, and
also the results of the following three commands run
as root as soon as possible after the error occurs:

# ls -dl /dev
drwxr-xr-x 22 root root 6280 2010-03-14 11:16 /dev
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2010-03-14 11:15 /dev/null
# su www-data -c 'ls -l /dev/null'
crw-rw-rw- 1 root root 1, 3 2010-03-14 11:15 /dev/null

Is there anything in your Apache config that might
be trying to chroot?

--Mike Bird


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003181252.37677.mgb-deb...@yosemite.net

Re: Apache2 chroot /dev/null permission denied

[Knowledge Seeker]

Thanks for the help.
Doing what was asked I figured out and solved the problem.
Another administrator added the option nodev  to the partition of the
chroot. Probably He did not umounted and mounted the partition after that
and the service did not stopped, when we restart the machine, the problem
appeared.

One question.
For security reasons, what the best mount options for the chroot partition?
nosuid I already have.
Is it advisable to have nodev on the chroot and mount another small
/chroot/dev partition (maybe ramdisk), without the nodev option containing
the null urandom and random devices?

Thanks again.

[ ]'s

On Thu, Mar 18, 2010 at 7:52 PM, Mike Bird mgb-deb...@yosemite.net wrote:

 On Wed March 17 2010 19:00:35 Knowledge Seeker wrote:
  That is the problem.
  The permission is set to 666 and the group is root.
  But it still don't work.

 Please post the exact complete error message, and
 also the results of the following three commands run
 as root as soon as possible after the error occurs:

 # ls -dl /dev
 drwxr-xr-x 22 root root 6280 2010-03-14 11:16 /dev
 # ls -l /dev/null
 crw-rw-rw- 1 root root 1, 3 2010-03-14 11:15 /dev/null
 # su www-data -c 'ls -l /dev/null'
 crw-rw-rw- 1 root root 1, 3 2010-03-14 11:15 /dev/null

 Is there anything in your Apache config that might
 be trying to chroot?

 --Mike Bird


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/201003181252.37677.mgb-deb...@yosemite.net




-- 
Knoseeker

Apache2 chroot /dev/null permission denied

[Knowledge Seeker]

Hi,
I have an old Debian Etch box, running Apache2 on chroot jail. Yesterday,
(it sounds like joke) I turned off the machine and when I started it again
the web server did not come to life again.
The problem was a Permission Denied on the /dev/null.

I created my device with the command:  mknod -m 0666 /chroot/dev/null c 1 3
listing the permissions:

crw-rw-rw- 1 root root 1, 3 2010-03-16 18:37 null
crw-rw-rw- 1 root root 1, 8 2010-03-16 18:39 random
crw-rw-rw- 1 root root 1, 9 2010-03-16 18:39 urandom


(When I change the group to sys, don't solve the problem)

Even outside of the chroot when I try to echo something and redirect to this
device I get the same message:

-su: null: Permission Denied

My kernel is the default:
2.6.18-6-686 #1 SMP

Everything worked fine 2 days ago.

I really wish to understand and solve this issue.
When I mount all /dev with a bind option, it works fine again, but I
wouldn't want to have all my devices available inside chroot.

I really appreciate any help.

Thanks in advance

-- 
Knoseeker

Re: Apache2 chroot /dev/null permission denied

[Wayne]

Knowledge Seeker wrote:

Hi,
I have an old Debian Etch box, running Apache2 on chroot jail. Yesterday,
(it sounds like joke) I turned off the machine and when I started it again
the web server did not come to life again.
The problem was a Permission Denied on the /dev/null.

I created my device with the command:  mknod -m 0666 /chroot/dev/null c 1 3
listing the permissions:

crw-rw-rw- 1 root root 1, 3 2010-03-16 18:37 null
crw-rw-rw- 1 root root 1, 8 2010-03-16 18:39 random
crw-rw-rw- 1 root root 1, 9 2010-03-16 18:39 urandom


(When I change the group to sys, don't solve the problem)

Even outside of the chroot when I try to echo something and redirect to this
device I get the same message:

-su: null: Permission Denied

My kernel is the default:
2.6.18-6-686 #1 SMP

Everything worked fine 2 days ago.

I really wish to understand and solve this issue.
When I mount all /dev with a bind option, it works fine again, but I


 I ran into that after an upgrade on squeeze a few months ago.  As a 
result a few programs would not run.  The atd daemon was the only one I 
cared about.  Don't know, yet, what caused it but the fix was to put the 
following into /root/.bash_profile.


chmod 666 /dev/null
chgrp root /dev/null

/etc/init.d/atd restart

HTH

Wayne


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4ba16444.4010...@gmail.com

Re: Apache2 chroot /dev/null permission denied

[Knowledge Seeker]

That is the problem.
The permission is set to 666 and the group is root.
But it still don't work.


On Wed, Mar 17, 2010 at 11:22 PM, Wayne linux...@gmail.com wrote:

 Knowledge Seeker wrote:

 Hi,
 I have an old Debian Etch box, running Apache2 on chroot jail. Yesterday,
 (it sounds like joke) I turned off the machine and when I started it again
 the web server did not come to life again.
 The problem was a Permission Denied on the /dev/null.

 I created my device with the command:  mknod -m 0666 /chroot/dev/null c 1
 3
 listing the permissions:

 crw-rw-rw- 1 root root 1, 3 2010-03-16 18:37 null
 crw-rw-rw- 1 root root 1, 8 2010-03-16 18:39 random
 crw-rw-rw- 1 root root 1, 9 2010-03-16 18:39 urandom


 (When I change the group to sys, don't solve the problem)

 Even outside of the chroot when I try to echo something and redirect to
 this
 device I get the same message:

 -su: null: Permission Denied

 My kernel is the default:
 2.6.18-6-686 #1 SMP

 Everything worked fine 2 days ago.

 I really wish to understand and solve this issue.
 When I mount all /dev with a bind option, it works fine again, but I


  I ran into that after an upgrade on squeeze a few months ago.  As a result
 a few programs would not run.  The atd daemon was the only one I cared
 about.  Don't know, yet, what caused it but the fix was to put the following
 into /root/.bash_profile.

 chmod 666 /dev/null
 chgrp root /dev/null

 /etc/init.d/atd restart

 HTH

 Wayne


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a
 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/4ba16444.4010...@gmail.com




-- 
Knoseeker

[SOLVED] Permission denied when changing fan speed on T23 (Lenny)

[Brian Ryans]

I forgot to mark my previous reply to this thread solved, silly me :)

I've also written a little script for the benefit of those who may have
a similiar problem in the future and find this via the archives or by
google. Due to the triviality of this script, I'm declaring it to be
public domain.

-- 
   _
   ASCII Ribbon Campaign Against  ( )   Brian Ryans
  HTML E-mail and V-cards  Xbrianlry...@gmail.com
www.asciiribbon.org   / \   GPG Public Key 0xC11213D0
 Key Fingerprint: 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0
#!/usr/bin/env sh
# Public-domain fan control script for IBM Thinkpad laptops. Tested on a T23.
# Very kludgy, use at your own risk, may contain bugs, no warranty, etc etc.

declare ibmfan='/proc/acpi/ibm/fan'

display_status() {
speed=$(grep ^speed $ibmfan | cut -d: -f2 | tr -d '[:space:]')
level=$(grep ^level $ibmfan | cut -d: -f2 | tr -d '[:space:]')
echo level $level at ${speed}rpm
}

# user entry point
[ -z $1 ]  display_status

action=$1
case $action in
0|1|2|3|4|5|6|7)echo level $action  $ibmfan ;;
f*|m*)  echo level full-speed  $ibmfan ;;
a*) echo level auto  $ibmfan ;;
esac


signature.asc
Description: Digital signature

Permission denied when tweaking various /proc knobs (Lenny)

[Brian Ryans]

I am attempting to adjust brightness via '/proc/acpi/ibm/brightness',
but I get permission denied if I do it via sudo -- I have to su to root
in order to do the adjustments. Log at [1].

[1]
bry...@esterhazy:~$ sudo echo up  /proc/acpi/ibm/brightness
bash: /proc/acpi/ibm/brightness: Permission denied
bry...@esterhazy:~$ su
Password:
esterhazy:/home/bryans# echo up  /proc/acpi/ibm/brightness
/* Display brightness increases */
[end 1]

I am in my /etc/sudoers file with all permissions. My /etc/sudoers file,
with comments stripped, is at [2].

[2]
Defaultsenv_reset
rootALL=(ALL) ALL
bryans  ALL=(ALL) ALL
[end 2]

My sudoers seems alright as I can execute other privileged commands with
no difficulty, just not mess around with the files in /proc (those few
I've tried)

I don't think it _can_ be a permissions issue, as by my understanding,
absolutely no permission checks are applied to root by userspace --
though correct me if I'm wrong.

I tried to sudo echo h  /proc/sysrq-trigger, and again was denied.
This led me to look in $linux/kernel/sysrq.c, but I found nothing
useful in determining why I can't do this using sudo.

I'm left to several possibilities:

1.  I'm misunderstanding some documentation somewhere (PEBKAC)
2.  sudo cannot allow me to do this, possibly due to restrictions
elsewhere in the kernel [3]
3.  I'm able to do this, but I'm just not looking in the right place for
how to enable it

[3] Highly unlikely, by my knowledge.

-- 
   _
   ASCII Ribbon Campaign Against  ( )   Brian Ryans
  HTML E-mail and V-cards  Xbrianlry...@gmail.com
www.asciiribbon.org   / \   GPG Public Key 0xC11213D0
 Key Fingerprint: 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0


signature.asc
Description: Digital signature

Re: Permission denied when tweaking various /proc knobs (Lenny)

[Sascha Silbe]

On Sat, Dec 05, 2009 at 11:22:37PM -0600, Brian Ryans wrote:


bry...@esterhazy:~$ sudo echo up  /proc/acpi/ibm/brightness
bash: /proc/acpi/ibm/brightness: Permission denied
The redirection is set up by the current shell, i.e. with non-elevated 
privileges. Try this instead:


sudo sh -c 'echo up  /proc/acpi/ibm/brightness'

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature

Re: Permission denied when tweaking various /proc knobs (Lenny)

[Sven Joachim]

On 2009-12-06 06:22 +0100, Brian Ryans wrote:

 I am attempting to adjust brightness via '/proc/acpi/ibm/brightness',
 but I get permission denied if I do it via sudo -- I have to su to root
 in order to do the adjustments. Log at [1].

 [1]
 bry...@esterhazy:~$ sudo echo up  /proc/acpi/ibm/brightness

This does not work because it is your shell, not sudo, that does the
redirection, as you can see in the error message:

 bash: /proc/acpi/ibm/brightness: Permission denied

Use one of the following commands:

$ echo up | sudo tee /proc/acpi/ibm/brightness
$ sudo sh -c echo up  /proc/acpi/ibm/brightness

See
https://help.ubuntu.com/community/RootSudo#Downsides%20of%20using%20sudo.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Permission denied when tweaking various /proc knobs (Lenny)

[Brian Ryans]

Thanks, I wasn't paying attention to the 'bash' part, only to the
'permission denied' part. : PEBKAC on my part.

-- 
   _
   ASCII Ribbon Campaign Against  ( )   Brian Ryans
  HTML E-mail and V-cards  Xbrianlry...@gmail.com
www.asciiribbon.org   / \   GPG Public Key 0xC11213D0
 Key Fingerprint: 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0


signature.asc
Description: Digital signature

Re: passwd: Permission denied ?

[Jon Dowland]

On Mon, Sep 21, 2009 at 03:37:01PM +0200, Sven Joachim wrote:
 No, they are not.  It's /etc/passwd, not /usr/bin/passwd.

Oops! (red with embarrassment)


signature.asc
Description: Digital signature

Re: passwd: Permission denied ?

[Jon Dowland]

On Fri, Sep 18, 2009 at 11:39:28AM +0200, Frank Bonnet wrote:

 -rw-r--r-- 1 root root 1358 2009-09-18 09:21 /etc/passwd

These permissions are wrong.

The missing suid bit (as someone else pointed out) will
prevent anyone but root using it.

The missing e(x)ecute bit will prevent even root.

Either restore +x (and +s), or something like

# /lib/ld-2.9.so /usr/bin/passwd

I would also worry about *precicely how* the permissions
were changed.


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: passwd: Permission denied ?

[Sven Joachim]

On 2009-09-21 15:27 +0200, Jon Dowland wrote:

 On Fri, Sep 18, 2009 at 11:39:28AM +0200, Frank Bonnet wrote:

 -rw-r--r-- 1 root root 1358 2009-09-18 09:21 /etc/passwd

 These permissions are wrong.

No, they are not.  It's /etc/passwd, not /usr/bin/passwd.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org