Hi Dennis,
> What is the state of selinux on your system? This is found in some
> distributions by running getenforce at the command line.
This is a stock debian jesse build. As I understand it, selinux is not
enabled by default, and I can find no evidence there are any policies in
effect.
>
Hi Bryan,
Thank you very much for contributing your thoughts to this thread.
> E.g. 007 permissions (--rwx) does *not* give 'everyone' read/write/execute
> permissions; it only gives people who are (1) not the owner/in the owner
> class, and (2)
> not in the owning group/in the group class.
Hello,
> > You might be. Please look at the permissions of the parent
> > directory.
> > You might then want to make changes to those permissions and once
> > more
> > repeat your tests. Note: In a *n[iu]x system you can delete a file
> > in
> > a directory to which you can write, even if you ca
On 7/30/13 11:18:36AM, Bob Miller wrote:
Hello,
I am trying to trace the reasoning behind behaviour I don't understand
with regard to permissions on the clamd.socket and simscan.
What is the state of selinux on your system? This is found in some
distributions by running getenforce at the comm
> How can world rw not work unless the user/group is
> correct, is this some sort of umask thing?
I think I can answer this one, at least. Thinking of the last permissions' set
as 'world'
is misleading. This last set is more properly the 'other' class. And in fact,
the first
two sets (owner and
- Original Message -
> Hi there,
>
> On Fri, 2 Aug 2013, Bob Miller wrote:
>
> > Were you expecting something different?
>
> Not necessarily, but it tells me something. :)
>
> > Or more likely, am I missing something obvious here?
>
> You might be. Please look at the permissions of
Hi there,
On Fri, 2 Aug 2013, Bob Miller wrote:
Were you expecting something different?
Not necessarily, but it tells me something. :)
Or more likely, am I missing something obvious here?
You might be. Please look at the permissions of the parent directory.
You might then want to make ch
