Re: Parfait and UoM (java) RPM packages

Hi,

On 2016-10-20 05:36, Nathan Scott wrote:
> ----- Original Message -----
>>>> [...]
>>>> *) Btw, what's the recommended way to enable MMV for non-root users? I did
> 
> This is described in the pmdammv(1) man page ''INSTALLATION'' section - I've
> had a few goes at trying to document this all clearly, so please send through
> any clarifications you can suggest - thanks!
> 
>>>  The
>>> current mmv ./Install script includes this bit:
>>>
>>> if [ ! -e "$PCP_TMP_DIR/mmv" ]
>>> then
>>>     echo "creating $PCP_TMP_DIR/mmv"
>>>     mkdir -p -m 1777 "$PCP_TMP_DIR/mmv"
>>> fi
> 
> Use of this script is covered in pmdammv(1) - see the paragraph about back-
> compat and the Install script.

I think the main concern is that although one could say that the man
page covers some of these concerns, it is done implicitly not explicitly
in some important areas. For example, when referring to "similar classes
of issues" like with system temp dir, the reader may easily start
thinking about a rogue user filing up the file system, not metrics being
overridden or a user being able to prevent others to get some metrics
(which is IMHO not even implicitly covered by the system temp dir
reference, cf. mkstemp(1)).

> <fche> I wonder if the mmv ./Install script is not actually being run somehow, and that pmda is enabled by some other means (and thus Install initialization  skipped)
> 
> ... this is correct - pmdammv is installed by default (just like pmdalinux,
> pmdapmcd, pmdaproc, etc) which means the Install script is typically never
> run.  An observant by-stander may notice many of those PMDAs don't even have
> Install scripts.
> 
> However - and as documented in the man page - we do not make a decision on
> the users behalf about the MMV security model they should be using.

Yes, a "good" and secure model should be offered consistently by
default, however it's not clear why the Install script and Parfait use
different permissions to create the directory in case it's missing?

>>> which makes the mmv directory world-writeable.  The sticky bit should
>>> prevent users from overwriting each other's files.  There are other
>>> security concerns (DoS, namespace squatting, etc.) that are not addressed.
> 
> ... is very misleading - these issues are indeed addressed, depending on the
> model chosen.  In situations that require such mitigation, hostile users can
> be prevented from being able to interact with pmdammv at all, preventing all
> of the concerns above.

I'm mostly concerned about accidents which can happen even without rogue
users. I don't know what the above "namespace squatting" or "etc" is
referring to in this context but I don't think the DoS aspect (if you
want call it such) has been clearly explained at least in the man page
(the man page doesn't even mention the possibility of DoS). As said,
with security concerns I'd very much prefer explicit rather than
implicit approach.

> Unfortunately, each approach had its tradeoffs and there's no one perfect way
> to go.  More secure means a more involved setup (and local knowledge needed),
> whereas the sticky bit approach is less secure (in general, but fine for ~99%
> of PCP users I imagine) and far, far easier to get people up and running.

Yeah, perfect solution for everyone is rarely realistic thus the next
best thing is to offer alternatives and provide documentation/guidance.

Thanks,

-- 
Marko Myllynen

-=-=-=-=-=-=-=-=-=-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14560): https://groups.io/g/pcp/message/14560
View All Messages In Topic (19): https://groups.io/g/pcp/topic/2895998
Mute This Topic: https://groups.io/mt/2895998?uid=174580
New Topic: https://groups.io/g/pcp/post

Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580

Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]

Terms of Service: https://groups.io/static/tos

Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-