Re: [DNG] gvfs depends on libsystemd0

[Arnt Karlsen]

On Tue, 11 Apr 2017 11:31:35 +0200, aitor_czr wrote in message 
:

> Hi Hendrik,
> 
> On 04/11/2017 12:17 AM, Hendrik Boom  wrote:
> > What is the status of vdev?  Is it packages and inthe repositories
> > yet? Is it too much to hope it;s available in jessie?
> >
> > -- hendrik
> 
> As fsmithred said in the irc, there are two sets of packages working
> for now:
> 
> https://git.devuan.org/devuan-packages/vdev (by Ralph Ronquist)
> 
> and:
> 
> deb http://packages.gnuinos.org/unsystemd jessie main
> deb-src http://packages.gnuinos.org/unsystemd jessie main
> 
> You have to run vdev-assistant in this second case. But be carefull
> with the "live" hook in the initramfs-tools, it needs some simple
> changes. Remove all the live-* packages from your system if they
> exist, before installing vdev.

..I forgot this bit, but fixed another assumption bug, the apt database
is not neccessarily working as it should, on a trashed systemd etc box:
root@trashed-systemd-etc-box:/var/cache/apt/archives# diff -U0 \
/usr/bin/vdev-assistant.org /usr/bin/vdev-assistant
--- /usr/bin/vdev-assistant.org 2016-12-29 14:24:21.0 +0100
+++ /usr/bin/vdev-assistant 2017-04-17 05:01:18.089053089 +0200 
@@ -35 +35,3 @@
-apt --reinstall install libudev1-compat
+#apt --reinstall install libudev1-compat
+dpkg -P libudev1-compat
+dpkg -Bi libudev1-compat*
@@ -37 +39,3 @@
- apt --reinstall install libudev-dev
+# apt --reinstall install libudev-dev
+dpkg -P libudev-dev
+   dpkg -Bi libudev-dev*
@@ -39,2 +43,4 @@
-mv /etc/insserv/overrides/vdev /etc/insserv/overrides/udev
-apt --reinstall install vdev
+mv -vf /etc/insserv/overrides/vdev /etc/insserv/overrides/udev
+#apt --reinstall install vdev
+dpkg -P vdev
+dpkg -Bi vdev*
@@ -52 +58 @@
-   apt-get install libvdev1
+   dpkg -Bi libvdev1*
@@ -54 +60 @@
-   apt-get install libudev1-compat
+   dpkg -Bi libudev1-compat*
@@ -57 +63 @@
- apt-get install libudev-compat-dev
+ dpkg -Bi libudev-compat-dev*
@@ -59 +65 @@
-   apt-get install libvdev-hwdb
+   dpkg -Bi libvdev-hwdb*
@@ -63,2 +69,2 @@
-   rm -f /usr/share/initramfs-tools/init
-   cp /usr/share/initramfs-tools/vdev-init/init 
/usr/share/initramfs-tools/
+   rm -vf /usr/share/initramfs-tools/init
+   cp -v /usr/share/initramfs-tools/vdev-init/init 
/usr/share/initramfs-tools/
@@ -66 +72 @@
-   apt-get install vdev
+   dpkg -Bi vdev*
@@ -78 +84 @@
-   dpkg --purge libvdev1
+   dpkg --purge libudev1
@@ -92 +98 @@
-   apt-get install libvdev1
+   dpkg -Bi libvdev1*
@@ -95 +101 @@
-   mv /etc/insserv/overrides/vdev /etc/insserv/overrides/udev
+   mv -v /etc/insserv/overrides/vdev /etc/insserv/overrides/udev
@@ -100 +106 @@
- apt-get install libudev-dev
+ dpkg -Bi libudev-dev*
@@ -104 +110 @@
-   apt-get install libudev1
+   dpkg -Bi libudev1*
@@ -106,2 +112,2 @@
-   rm -f /usr/share/initramfs-tools/init
-   cp /usr/share/initramfs-tools/udev-init/init 
/usr/share/initramfs-tools/
+   rm -fv /usr/share/initramfs-tools/init
+   cp -v /usr/share/initramfs-tools/udev-init/init 
/usr/share/initramfs-tools/
@@ -109,2 +115,2 @@
-   rm -f /etc/insserv/overrides/udev
-   apt-get install udev
+   rm -fv /etc/insserv/overrides/udev
+   dpkg -Bi udev*

..those funny lines missing "+" and "-" starting "/", are long 
and broken. ;o)


> Now, the priority are the manpages. You can read more here:
> 
> https://dev1galaxy.org/viewtopic.php?id=43
> 
> Recently i tried to run a devuan vanilla with vdev and a 4.x kernel,
> and it didn't work (in live mode) because the system searched for a
> cdrom_id binary, non existent in vdev. On the other hand, you will
> need to set your keyboard configuration at every reboot (minor issue)
> depending on your keymap. Beyond that,vdev works fine for me.
> 
> Cheers,
> 
>Aitor.
> 
> 
> 


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

Il 13/04/2017 16:55, Rick Moen ha scritto:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>   This is what can be logically inferred from what you wrote.
> No.

  Yep.

> I'm sorry this conversation was not fruitful, which as mentioned is why I have
> disengaged.  Have a great day.

  Once more you state so, and once more you disprove yourself.

-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>   This is what can be logically inferred from what you wrote.

No.

I'm sorry this conversation was not fruitful, which as mentioned is why I have
disengaged.  Have a great day.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

On Wed, 12 Apr 2017 at 14:18:34 -0700 Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>   As sudo can be made to operate either requiring the user to type his
>> own password or no password, stating (now) that just "a particular usage
>> model" of sudo constiutes a proxy for the superuser's password can only
>> refer to the case the user has to type his password.  If you think using
>> an unprivileged user's password to carry out privileged tasks will lead
>> to a root password bypass by some attacker
>
> I did not so claim.

  This is what can be logically inferred from what you wrote.

> I honestly think my point was abundantly clear.

  No, every time, now included, you always failed to explain how in the world
could typing the superuser's password be considered safer that typing an
underprivileged user's one or no password at all when one has to mount a
filesystem.

>  And I really have no
> desire to argue.

  You stated this over and over again but you always failed following up on
your own words.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[aitor_czr]

Hi KatolaZ,

... and sorry for my delay...

On 04/11/2017 02:00 PM, KatolaZ  wrote:

Thanks aitor. It would be great to have vdev in ascii, innit?


Yes, it should be added in asci/ceres, not in jessie.


Do you think it might be possible to try building the vdev package through
the Devuan CI system, and put it in experimental, so that people can
start playing with it?

HND

KatolaZ


I would like it, of course. I never used Jenkins :)

Cheers,

  Aitor.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>   As sudo can be made to operate either requiring the user to type his
> own password or no password, stating (now) that just "a particular usage
> model" of sudo constiutes a proxy for the superuser's password can only
> refer to the case the user has to type his password.  If you think using
> an unprivileged user's password to carry out privileged tasks will lead
> to a root password bypass by some attacker

I did not so claim.

I honestly think my point was abundantly clear.  And I really have no
desire to argue.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

Il 12/04/2017 03:32, Rick Moen ha scritto:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> I argued against the assertion by Rick Moen that sudo constitutes "a
>> proxy for the root password"...
> I did not so state.
>
> I characterised a particular usage model of sudo as such.

  As sudo can be made to operate either requiring the user to type his
own password or no password, stating (now) that just "a particular usage
model" of sudo constiutes a proxy for the superuser's password can only
refer to the case the user has to type his password.  If you think using
an unprivileged user's password to carry out privileged tasks will lead
to a root password bypass by some attacker, one can hardly figure how
you might think using no password at all could not constitute at least
as dangerous attack vector, so your point about the alleged oot password
proxy related to just a specific "usage model" of sudo is moot.

  Of course you always skipped any explanation about how could you think
that typing the superuser's password for such a menial task as mounting
a filesystem (something Unix systems have done for decades) could be
thought of as a more secure approach to password and system protection
than typing an unprivileged user's one or no password at all.



-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> I argued against the assertion by Rick Moen that sudo constitutes "a
> proxy for the root password"...

I did not so state.

I characterised a particular usage model of sudo as such.

As for the rest, if it's not apparent to you that letting a credential
for normal user login also suffice for root privilege weakens security 
over escalation to root requiring a separate password, I would prefer to
abandon further discussion as fruitless, and I do regret that this
turned out to be the case.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Dragan FOSS]

On 04/11/2017 01:27 AM, aitor_czr wrote:

As i can see, lines like:


As I can see, your version needs one more patch :)

***
--- 
/media/dragan/TRIOS/TMP/Aitor/gvfs-master-64caae2fe2bdd1aeb2d65cdcdb326f170718eb2a/debian/control

+++ /media/dragan/TRIOS/TMP/Adam/gvfs-1.22.2/debian/control
@@ -41,7 +41,6 @@
libimobiledevice-dev (>= 1.1.5) [!hurd-any],
libplist-dev,
libudisks2-dev (>= 1.97) [linux-any],
-   libsystemd-login-dev (>= 44) [linux-any],
libgtk-3-dev
 Standards-Version: 3.9.6
 Homepage: https://wiki.gnome.org/Projects/gvfs
***

Cheers,
Dragan

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Hendrik Boom]

On Tue, Apr 11, 2017 at 12:55:37PM +0100, KatolaZ wrote:
> 
> OK, but you would agree that, if you find yourself in such an
> "unprotected enviroment", there is not much difference between typing
> the root password and typing the password of a user who can become
> root by "sudo su".

This is true only if you configure sudo to allow the use of su.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

On Tue, 11 Apr 2017 at 12:55:37 +0100
KatolaZ  wrote:

> On Tue, Apr 11, 2017 at 01:34:19PM +0200, Alessandro Selli wrote:
> 
> [cut]
> 
> >   One cannot avoid using at least once his own password at the start of
> > the session, so this password cannot be completely secured when operating
> > in an open or unprotected environment.  If need arises to perform, in
> > that same environment, a task that requires root privileges, then sudo is
> > the easiest way to perform that task without exposing the superuser's
> > password at all.
> > 
>
> OK, but you would agree that, if you find yourself in such an
> "unprotected enviroment", there is not much difference between typing
> the root password and typing the password of a user who can become
> root by "sudo su".

  No, I do not agree.  There is in fact a big difference: would someone gain
knowledge of your unpriviledged user's password, then would attackers
manage to have a shell access to your PC they whould only be able to do what
you can do and what you configured sudo to let your user do. Gaining knowledge
of the superser's password allows unrestricted access to all the systems'
resources after a shell is obtained.

> No automagic can replace a reasonable behaviour, especially when it
> comes to security.

  Of course.  I do state anyway that sudo is inherently more secure than su.

> The worst aspect of sudo is that it has deluded
> users in thinking that the sudo-way is "more secure".

  Again, every useful security tool can be misconfigured and abused into a
security hazard.  ssh can be, PAM can be, LDAP can be, SSL/TLS can be,
Kerberos can be, SUID is, Linux Capabilities can be, ACL can be and so on and
on. This is however just a pretext when arguing against the use of these
tools.




-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[KatolaZ]

On Tue, Apr 11, 2017 at 01:34:19PM +0200, Alessandro Selli wrote:

[cut]

>   One cannot avoid using at least once his own password at the start of the
> session, so this password cannot be completely secured when operating in an
> open or unprotected environment.  If need arises to perform, in that same
> environment, a task that requires root privileges, then sudo is the easiest
> way to perform that task without exposing the superuser's password at all.
> 

OK, but you would agree that, if you find yourself in such an
"unprotected enviroment", there is not much difference between typing
the root password and typing the password of a user who can become
root by "sudo su".

No automagic can replace a reasonable behaviour, especially when it
comes to security. The worst aspect of sudo is that it has deluded
users in thinking that the sudo-way is "more secure". Which is totally
BS (I mean Brutally Simplistic, obviously).

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

On Tue, 11 Apr 2017 at 07:13:36 +0100
Klaus Ethgen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Mo den 10. Apr 2017 um 22:09 schrieb Alessandro Selli:
> >   You still should use sudo, with a password - the user's own password. 
> > Using root password many times, every day, is bad for security (the more
> > times you type it the higher the chances are it will be captured)
>
> That is a common misunderstanding.
>
> If you have (like many people) have your account allowed to do
> everything with sudo, than it doesn't matter if you have to type the
> root password or your own. If a attacker can get hand on one of that
> two, he can use it.

  Setting up sudo to allow an unprivileged account to perform any action with
superuser privileges with no password is bad security practice, and I never
supported or argued in it's favor.
  Assuming that the fact that sudo could be misconfigured and abused is a
valid point against it's use is the same as stating that ssh certificates
could be generated with weak hashes and protected by poorly chosen
passphrases, and that it should for this reason not be used.

> Moreover, it raises the attack vector from one password to two.

  I argued against the assertion by Rick Moen that sudo constitutes "a proxy
for the root password", while I was advocating it's use as a way to avoid
completely any use of the superuser password, thus preventing it from been
exposed.
  One cannot avoid using at least once his own password at the start of the
session, so this password cannot be completely secured when operating in an
open or unprotected environment.  If need arises to perform, in that same
environment, a task that requires root privileges, then sudo is the easiest
way to perform that task without exposing the superuser's password at all.

> That stupid use of sudo (That was initialize introduced by ubuntu)
> should have an end.

  The fact that some stupid people configure useful tools in a stupid way
does not prove that those tools are bad.  It only proves that there are
stupid people.  And I do know there are way more people who chose ease of use
to security: this is not a good reason because I forgo using the right tools
the right way.
  Taking the bad practices of Ubuntu as a reason to do away with sudo
entirely is stupid, too.  It's like stating that PAM should  be eradicated
from any GNU/Linux distribution because some stupid folk staffed /etc/pam.d/*
files with lines like:

password sufficient pam_unix.so nullok minlen=0

> Another think is if (or not) you should allow login as root via password
> at all.

  Locally yes, of course, over selected secure terminals.  Not over the
network, for sure.

> Regards
>Klaus
> - -- 
> Klaus Ethgen   http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
> 
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAljsdA8ACgkQpnwKsYAZ
> 9qw9eQwAoVxp91qFTzDq0AEGXs4IJqnpPu/rJ5jbkcyOCCRnBJB/Lrr/CyBB6HcF
> xvVwHy2ReprGpUEOhnPQxPujtL0JLFzw0wrs2W8m29R/NudgI26j4Yu3FVtOYacc
> kvNofJfp6o8gRvgE8ontlNY8VheKLy9d8G/tub1SyiYg9vqZ7uizCee0UWD1wB+n
> T7U3ZX1Do6mPim1no03SrfQ25dHSRND3JaRYfg2wgV+ACaVtKOfkaTtMLCV6O8xJ
> L/3jMBvAxgRrxl11zEQyeKsRUkbgVvt14VRPW/f8p7NqDJRRPffU0+2xN5yrltRi
> z4n47ynBWdsIJIFdJ5nq4UQdsq3F8kT/PBL9gNw5DjO8EZY921EIiALF3NC88K4C
> QjATaCWggznidyz4Pm1bJ13474uo9htX42UBngTgi0ESFdNNtXCUiDC9+ApyQTlp
> AM9odcsdrLY/FGNj2c99TI2Cb77OXzeACBRToIfhIGCiydoSnA873yggIR/WRD/5
> P1xeWINK
> =KNz/
> -END PGP SIGNATURE-
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

Il giorno Tue, 11 Apr 2017 05:28:29 +0200
marc  ha scritto:

> >   You still should use sudo, with a password - the user's own password. 
> > Using root password many times, every day, is bad for security (the more
> > times you type it the higher the chances are it will be captured) and it
> > instills the desire of an easy to remember and fast to type password.
> 
> 
> What people often overlook is that having a real root password
> is that is possible to press control-alt-F2 and log in as
> root on a text console.

  You still have to type the superuser's password, so you gain almost no
more protection.

> To intercept the password in that case typically requires root
> anyway, or some sort of physical access - in either case the
> game is already over.

  Having to type the superuser password for tasks that could be configured to
work without is bad; it's only a matter of time before you have to choose
between typing it in an unprotected environment (in an airport,
bus terminal, in an openspace, any place crowded with people, cameras and
microphones) or forgo taking advantage of a basic OS' function when actually
needed.

> This is different to using sudo or su, where a random javascript
> exploit can control firefox which then straces your xterm or
> updates your .bashrc to grab your password the next time you
> type su or sudo.

  This is true of whatever you do with your PC and browser.  "The only
totally secure PC is a PC with it's power plug pulled off".

  Anyway, what is worse, having that jscript capture your system's
superuser password, or your unprivileged user's that is now running firefox?

[...]

> Sudo has its uses, but the practice of using sudo and no root
> password is a convenience (fewer passwords to remember) which
> typically weakens security.

  No, it's mostly security: having to type the superuser's password when
easily avoidable exposes the system's most critical password to be
captured.  There are many circumstances when typing *any* password is just
crazy, let alone the superuser one.  If some privileged task has to be
carried out in an unsecure environment, su is the command to avoid.  You
either have sudo (or some other like tool) preconfigured to perform that task
with no password or, at most, with your unprivileged user password.  Of
course doing nothing is the most secure option, but if you have a PC I
suppose you have it for a purpose, to run it and take advantage of it's
capabilities.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

Il giorno Mon, 10 Apr 2017 15:17:46 -0700
Rick Moen  ha scritto:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
> >   IMO, using root's password in those same cases is the worst possible
> > password use case.  One thing is your non-privileged user's password
> > being captured when you mount an external drive, a different thing is
> > giving away root's password performing the same trivial task.
> 
> You might have missed my point that your suggestion makes that
> 'non-privileged user's password' privileged -- such that every time you
> use it in any situation, you are exposing a privleged password.  Which 
> I deem very undesirable.

 You might have missed my point that your use of *superuser* password when
unneeded exposes that privileged password when it can easily be avoided in
serveral ways, that either expose an unpriviledged password or does not
require any.

>>> but it also has a secondary use to escalate privilege to root.
>> 
>> Just like using su does.
>
> 'su -' does of course escalate (obviously), but _not_ as a secondary use
> of an otherwise non-privileged login.

  Right.  It "only" exposes the system's *superuser* password.

>  But I think the point should be
> clear, and I don't care to keep re-discussing this point.
>
> Anyway, I'm glad whatever you do works for you.

  I did not argue that my way works and other people's does not.  I'm
only stating the obvious: using the root user's password for simple tasks
that are easily configured in many alternative ways to work without requiring
the user to type the superuser password exposes the most critical system
password to be recorded/intercepted/glanced etc.

>> Needing to type it just to mount an external drive increases the
>> chances it will be used many times when easily avoidable.
>
> As already mentioned, this does not describe my experience.

  So what?  Do you adopt security measures to counter vulnerabilities or
neutralize attack vectors only *after* you personally suffered a security
breach?

>>  This too would be a better solution than having to use su to just
>> mount external drives.
>
> I do not concur, because IMO mounting/umounting is, in the general case,
> security sensitive and ought to be treated with caution, which includes
> not permitting arbitrary mounts/umounts by unprivileged users.

  sudo does permit selected users perform selected operations as another
user.  When it's configured to allow any user perform any task as the
superuser than it's been abused.  But assuming that the possibility of sudo
to be misconfigured and abused is a valid point to argue against it's use is
like arguing against setting any password to the superuser because it's
possible that people set a weak password on that user.

>  But I
> think the point should be clear, and I don't care to keep re-discussing
> this point.
>
>> This is precisely the reason I suggested using sudo, which allows
>> fine-tuning who gets to do what as another user.
>
> IMO mounting/umounting is, in the general case, security sensitive and
> ought to be treated with caution,

  I agree, this is exactly the reason I think mounting/unmounting external
devices should be either configured in /etc/fstab or under sudo or some
other secure mechanism. There is however no connection between the fact that
mounting devices is a potential security sensitive operation and the fact
that the more often a user has to type the root user's password
(expecially when unneccessary) increases the chances that this password is
captured by a third party.

> which includes not permitting
> arbitrary mounts/umounts by unprivileged users.

  sudo can be used to allow only some selected users to perform
mountig/unmounting of some selected drives onto selected directories.  The
implication that use of sudo per se exposes any unprivileged user to perform
"arbitrary mounts/umounts" is baseless.  The fact that administrative tools
can be misconfigured and abused does not prove that those tools are bad for
security, otherwise one could well argue against the use of each of them,
starting from PAM and ending with Kerberos.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[KatolaZ]

On Tue, Apr 11, 2017 at 11:31:35AM +0200, aitor_czr wrote:

[cut]

> 
> Now, the priority are the manpages. You can read more here:
> 
> https://dev1galaxy.org/viewtopic.php?id=43
> 
> Recently i tried to run a devuan vanilla with vdev and a 4.x kernel, and it
> didn't work (in live mode) because the system searched for a cdrom_id
> binary, non existent in vdev. On the other hand, you will need to set your
> keyboard configuration at every reboot (minor issue) depending on your
> keymap. Beyond that,vdev works fine for me.
> 

Thanks aitor. It would be great to have vdev in ascii, innit? Do you
think it might be possible to try building the vdev package through
the Devuan CI system, and put it in experimental, so that people can
start playing with it? 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mo den 10. Apr 2017 um 22:09 schrieb Alessandro Selli:
>   You still should use sudo, with a password - the user's own password. 
> Using root password many times, every day, is bad for security (the more
> times you type it the higher the chances are it will be captured)

That is a common misunderstanding.

If you have (like many people) have your account allowed to do
everything with sudo, than it doesn't matter if you have to type the
root password or your own. If a attacker can get hand on one of that
two, he can use it.

Moreover, it raises the attack vector from one password to two.

That stupid use of sudo (That was initialize introduced by ubuntu)
should have an end.

Another think is if (or not) you should allow login as root via password
at all.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAljsdA8ACgkQpnwKsYAZ
9qw9eQwAoVxp91qFTzDq0AEGXs4IJqnpPu/rJ5jbkcyOCCRnBJB/Lrr/CyBB6HcF
xvVwHy2ReprGpUEOhnPQxPujtL0JLFzw0wrs2W8m29R/NudgI26j4Yu3FVtOYacc
kvNofJfp6o8gRvgE8ontlNY8VheKLy9d8G/tub1SyiYg9vqZ7uizCee0UWD1wB+n
T7U3ZX1Do6mPim1no03SrfQ25dHSRND3JaRYfg2wgV+ACaVtKOfkaTtMLCV6O8xJ
L/3jMBvAxgRrxl11zEQyeKsRUkbgVvt14VRPW/f8p7NqDJRRPffU0+2xN5yrltRi
z4n47ynBWdsIJIFdJ5nq4UQdsq3F8kT/PBL9gNw5DjO8EZY921EIiALF3NC88K4C
QjATaCWggznidyz4Pm1bJ13474uo9htX42UBngTgi0ESFdNNtXCUiDC9+ApyQTlp
AM9odcsdrLY/FGNj2c99TI2Cb77OXzeACBRToIfhIGCiydoSnA873yggIR/WRD/5
P1xeWINK
=KNz/
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Stephanie Daugherty]

On Mon, Apr 10, 2017 at 11:28 PM, marc  wrote:

> >   You still should use sudo, with a password - the user's own password.
> > Using root password many times, every day, is bad for security (the more
> > times you type it the higher the chances are it will be captured) and it
> > instills the desire of an easy to remember and fast to type password.
>
>

As an aside here, avoid using sudo to allow untrusted or minimally trusted
users to mount filesystems.  There is a "user" option as well as an "owner"
option in /etc/fstab, and default installations of /bin/mount are setuid
root, allowing them to mount filesystems configured to be user-accessible
according to administrator-determined settings without su or sudo.

While this probably isn't completely secure, the attack surface is much
smaller and it's much more secure than most mere mortals will be able to
achieve with sudo, as correctly configuring sudo to limit the range of
possible inputs is difficult to understand and prone to human error, where
mount is instead rigidly limited to the approved mountpoints, devices,
filesystem types, and options by design. Making a filesystem user mountable
via fstab even implies noexec, nosuid, and nodev!

There are still the potential security issues of a buggy /bin/mount
executable and a buggy filesystem, but this approach at least eliminates a
wide range of creative ways through which /bin/mount or the shell could be
tricked into running a second executable with root permissions via sudo.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[marc]

>   You still should use sudo, with a password - the user's own password. 
> Using root password many times, every day, is bad for security (the more
> times you type it the higher the chances are it will be captured) and it
> instills the desire of an easy to remember and fast to type password.


What people often overlook is that having a real root password
is that is possible to press control-alt-F2 and log in as
root on a text console.

To intercept the password in that case typically requires root
anyway, or some sort of physical access - in either case the
game is already over.

This is different to using sudo or su, where a random javascript
exploit can control firefox which then straces your xterm or
updates your .bashrc to grab your password the next time you
type su or sudo.

And the common use-case for typing in a root password is to
mount a removable disk when one is physically at the computer,
where control-alt-F2 is accessible.

Sudo has its uses, but the practice of using sudo and no root
password is a convenience (fewer passwords to remember) which
typically weakens security.

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[aitor_czr]

Hi Dragan,

On 04/11/2017 12:17 AM, Dragan FOSS  wrote:

On 04/10/2017 01:19 PM, aitor_czr wrote:

I removed the dependency on *libsystemd0*:


gvfs (1.22.2-1.0nosystemd1) nosystemd; urgency=medium

* Non-maintainer upload.
* Cure systemd infestation.

   -- Adam Borowski   Mon, 01 Dec 2014 07:28:04 +0100

http://angband.pl/debian/pool/main/g/gvfs/gvfs_1.22.2-1.0nosystemd1.debian.tar.xz
*


:)


As i can see, lines like:


tmpfilesddir = $(prefix)/lib/tmpfiles.d
tmpfilesd_DATA = gvfsd-fuse-tmpfiles.conf


and:


EXTRA_DIST = \
gvfsd-fuse-tmpfiles.conf\
$(NULL)


are present in "client/Makefile.am", even though

usr/lib/tmpfiles.d/gvfsd-fuse-tmpfiles.conf

has been removed from "gvfs-common.install"

Cheers,

  Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>   IMO, using root's password in those same cases is the worst possible
> password use case.  One thing is your non-privileged user's password
> being captured when you mount an external drive, a different thing is
> giving away root's password performing the same trivial task.

You might have missed my point that your suggestion makes that
'non-privileged user's password' privileged -- such that every time you
use it in any situation, you are exposing a privleged password.  Which 
I deem very undesirable.

>> but it also has a secondary use to escalate privilege to root.
> 
> Just like using su does.

'su -' does of course escalate (obviously), but _not_ as a secondary use
of an otherwise non-privileged login.  But I think the point should be
clear, and I don't care to keep re-discussing this point.

Anyway, I'm glad whatever you do works for you.

> Needing to type it just to mount an external drive increases the
> chances it will be used many times when easily avoidable.

As already mentioned, this does not describe my experience.

>  This too would be a better solution than having to use su to just
> mount external drives.

I do not concur, because IMO mounting/umounting is, in the general case,
security sensitive and ought to be treated with caution, which includes
not permitting arbitrary mounts/umounts by unprivileged users.  But I
think the point should be clear, and I don't care to keep re-discussing
this point.

> This is precisely the reason I suggested using sudo, which allows
> fine-tuning who gets to do what as another user.

IMO mounting/umounting is, in the general case, security sensitive and
ought to be treated with caution, which includes not permitting
arbitrary mounts/umounts by unprivileged users.  But I think the point
should be clear, and I don't care to keep re-discussing this point.

>  This too is much better than having to use su.

IMO mounting/umounting is, in the general case, security sensitive and
ought to be treated with caution, which includes not permitting
arbitrary mounts/umounts by unprivileged users.  But I think the point
should be clear, and I don't care to keep re-discussing this point.

Anyway, I'm glad whatever you do works for you.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

On 10/04/2017 at 23:43, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>   You still should use sudo, with a password - the user's own password. 
>> Using root password many times, every day, is bad for security (the more
>> times you type it the higher the chances are it will be captured) and it
>> instills the desire of an easy to remember and fast to type password.
> Sorry to say, I do not concur with either these assumptions or the chain
> of reasoning provided.  For the most part, I've already said why, so if
> your view on that is different, we can reasonably just agree to
> disagree.
>
> Using a user password as a proxy for the root password is a lot worse
> for security, IMO -- and in fact hugely weakening of overall system
> security because you use it in a variety of other places for
> non-sensitive use-cases,

  IMO, using root's password in those same cases is the worst possible
password use case.  One thing is your non-privileged user's password
being captured when you mount an external drive, a different thing is
giving away root's password performing the same trivial task.

> but it also has a secondary use to escalate
> privilege to root.

  Just like using su does.

>   (Also, no, I do _not_ end up su'ing to root many
> times every day or typically more than once in very many days.)

  Well, at work I often need to use both my own of fellow colleagues'
drives.  But your experience might be well different compared to mine.

> Something would have to be quite unusual to require using the root
> password many times every day, in my experience.

  Needing to type it just to mount an external drive increases the
chances it will be used many times when easily avoidable.

>   E.g., sometimes people
> forget that many needs can be achieved through suitable group
> membership.

  This too would be a better solution than having to use su to just
mount external drives.

>  However, as I said to Steve Litt, IMO mounting/umounting
> is, in the general case, security sensitive and ought to be treated with
> caution, which includes not permitting arbitrary mounts/umounts by 
> unprivileged users.

  This is precisely the reason I suggested using sudo, which allows
fine-tuning who gets to do what as another user.

>   (As someone else said, standard mounts can/should
> be automated using autofs, where appropriate.)

  This too is much better than having to use su.

> If your views differ, I am glad that works for you.

  I actually do not use sudo to mount external drives, just to
cryptsetup then open/close.



-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>   You still should use sudo, with a password - the user's own password. 
> Using root password many times, every day, is bad for security (the more
> times you type it the higher the chances are it will be captured) and it
> instills the desire of an easy to remember and fast to type password.

Sorry to say, I do not concur with either these assumptions or the chain
of reasoning provided.  For the most part, I've already said why, so if
your view on that is different, we can reasonably just agree to
disagree.

Using a user password as a proxy for the root password is a lot worse
for security, IMO -- and in fact hugely weakening of overall system
security because you use it in a variety of other places for
non-sensitive use-cases, but it also has a secondary use to escalate
privilege to root.  (Also, no, I do _not_ end up su'ing to root many
times every day or typically more than once in very many days.)

Something would have to be quite unusual to require using the root
password many times every day, in my experience.  E.g., sometimes people
forget that many needs can be achieved through suitable group
membership.  However, as I said to Steve Litt, IMO mounting/umounting
is, in the general case, security sensitive and ought to be treated with
caution, which includes not permitting arbitrary mounts/umounts by 
unprivileged users.  (As someone else said, standard mounts can/should
be automated using autofs, where appropriate.)

If your views differ, I am glad that works for you.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[KatolaZ]

On Mon, Apr 10, 2017 at 11:09:44PM +0200, Alessandro Selli wrote:

[cut]

> 
>   You still should use sudo, with a password - the user's own password. 
> Using root password many times, every day, is bad for security (the more
> times you type it the higher the chances are it will be captured) and it
> instills the desire of an easy to remember and fast to type password.
>   IMO the best solution is having sudo run scripts that mount unknown
> devices (i.e., not configured in /etc/fstab) on directories under /mnt,
> and maybe create them if needed.
> 


...or just use pmount, and add any user with a compelling need to
mount devices to the "plugdev" group. And no password is ever needed.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Alessandro Selli]

Il 10/04/2017 02:25, Rick Moen ha scritto:
> Quoting Steve Litt (sl...@troubleshooters.com):
>
>> I think I know why, but I'll ask you anyway. Why don't you just put
>> mount in /etc/sudoers and make it not require a password?
> IMO, mounting / umounting is a sensitive operation (which is why Unix
> makes it be that way, unless you screw with it) and should be treated as
> such.
>
> Also, I typically don't bother to set up sudo on my own systems.
> Never really saw a compelling advantage, and I like to keep a nice,
> clean distinction between privileged shells and non-privileged ones.
>

  You still should use sudo, with a password - the user's own password. 
Using root password many times, every day, is bad for security (the more
times you type it the higher the chances are it will be captured) and it
instills the desire of an easy to remember and fast to type password.
  IMO the best solution is having sudo run scripts that mount unknown
devices (i.e., not configured in /etc/fstab) on directories under /mnt,
and maybe create them if needed.




-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Dragan FOSS]

On 04/10/2017 01:19 PM, aitor_czr wrote:

I removed the dependency on *libsystemd0*:


gvfs (1.22.2-1.0nosystemd1) nosystemd; urgency=medium

  * Non-maintainer upload.
  * Cure systemd infestation.

 -- Adam Borowski   Mon, 01 Dec 2014 07:28:04 +0100

http://angband.pl/debian/pool/main/g/gvfs/gvfs_1.22.2-1.0nosystemd1.debian.tar.xz
*


:)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Hendrik Boom]

On Mon, Apr 10, 2017 at 03:27:22PM +0200, aitor_czr wrote:

> 
> and udisks works without udev and libsystemd0... thanks to vdev :)

What is the status of vdev?  Is it packages and inthe repositories yet?  
Is it too much to hope it;s available in jessie?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[aitor_czr]

Hi KatolaZ,

On 04/10/2017 01:37 PM, KatolaZ  wrote:

On Mon, Apr 10, 2017 at 01:19:00PM +0200, aitor_czr wrote:

[cut]


I still don't know the reason for using the 1.26.2 upstream version of gvfs
in devuan. The version in debian jessie is 1.22.2, and we*should*  mantain
the same one in devuan, which is that i used. I talked about this months ago
in the IRC Channel.


Hi aitor,

devuan jessie currently has 1.22.2-1:

   $ apt-cache policy gvfs
   gvfs:
 Installed: (none)
 Candidate: 1.22.2-1
 Version table:
 1.22.2-1 0
 500http://auto.mirror.devuan.org/merged/  jessie/main amd64 Packages
   $

and it does not depend on libsystemd0. The package that depends on
libsystemd0 is gvfs-daemons, on which gvfs depens in turn.

My2Cents

KatolaZ
You are right, the version of both gvfs and gvfs-daemons is 1.22.2 as i 
can see in:


http://auto.mirror.devuan.org/merged/dists/jessie/main/binary-amd64/Packages.gz

But, running:

$ apt-get source gvfs

i get 1.26.2

In any case, as you said, gvfs-daemons depends on libsystemd0. My 
changes in those files mentioned above remove it.


Here you are its control file:

http://gnuinos.org/control

and udisks works without udev and libsystemd0... thanks to vdev :)

Cheers,

  Aitor.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[KatolaZ]

On Mon, Apr 10, 2017 at 01:19:00PM +0200, aitor_czr wrote:

[cut]

> 
> I still don't know the reason for using the 1.26.2 upstream version of gvfs
> in devuan. The version in debian jessie is 1.22.2, and we *should* mantain
> the same one in devuan, which is that i used. I talked about this months ago
> in the IRC Channel.
> 

Hi aitor,

devuan jessie currently has 1.22.2-1:

  $ apt-cache policy gvfs
  gvfs:
Installed: (none)
Candidate: 1.22.2-1
Version table:
1.22.2-1 0
500 http://auto.mirror.devuan.org/merged/ jessie/main amd64 Packages
  $

and it does not depend on libsystemd0. The package that depends on
libsystemd0 is gvfs-daemons, on which gvfs depens in turn.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[aitor_czr]

Hi Joachim,

On 04/10/2017 01:04 AM, Joachim Fahrner  wrote:

Hi,
how can I get rid of libsystemd0? gvfs depends on it, and without
gvfs PCmanFM does not mount external usb drives. Is there a way to
user mount external drives without gvfs?

Jochen

I removed the dependency on *libsystemd0*:

https://gitlab.com/aitor_czr/gvfs/tree/master

doing some changes for that in the following files:

- client/Makefile.am
- debian/gvfs-common.install
- debian/control

Here you are the packages (only in i386, at the time being):

http://gnuinos.org/gvfs/

But you can clone it from gitlab and build it using git-buildpackage.

I still don't know the reason for using the 1.26.2 upstream version of 
gvfs in devuan. The version in debian jessie is 1.22.2, and we *should* 
mantain the same one in devuan, which is that i used. I talked about 
this months ago in the IRC Channel.


Hmm...

With AntoFox? Maybe?

On the other hand, the po/Makefile.in.in is missing in the sources of 
1.26.2 in Devuan.


Cheers,

  Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Joachim Fahrner]

Am 2017-04-10 00:39, schrieb Daniel Abrecht:

I think automatically mounting thumb drives is very different from
mounting them when I klick on them in my file manager. Things like
automatically mounting removable medias or even auto starting
applications, I don't want that.


I also don't like automount on usb drives. I like to see them appear 
automatically in the filemanager, mount them as needed with a single 
click, and unmount them also with a single click to remove them.


For drives that should automount (such as NAS) I use autofs.

Jochen

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> I think I know why, but I'll ask you anyway. Why don't you just put
> mount in /etc/sudoers and make it not require a password?

IMO, mounting / umounting is a sensitive operation (which is why Unix
makes it be that way, unless you screw with it) and should be treated as
such.

Also, I typically don't bother to set up sudo on my own systems.
Never really saw a compelling advantage, and I like to keep a nice,
clean distinction between privileged shells and non-privileged ones.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Adam Borowski]

On Sun, Apr 09, 2017 at 10:39:28PM +, Daniel Abrecht wrote:
> On 04/09/2017 08:01 PM, Steve Litt wrote:
> > On Sun, 09 Apr 2017 08:24:15 +0200
> > Joachim Fahrner  wrote:
> >> without gvfs PCmanFM does not mount external usb drives
> >
> > Somewhere back in the archives I submitted a shellscript to
> > automatically mount thumb drives without a file manager.
> 
> I think automatically mounting thumb drives is very different from
> mounting them when I klick on them in my file manager. Things like
> automatically mounting removable medias or even auto starting
> applications, I don't want that. What if I want to rescue a faulty
> thumb drives for example, automatically mounting it would could
> damage it even further. I think that Linux doesn't do or change things
> on it's own like Windows used to be a big strength of it.

Automatically mounting is a security hole.  Last millenium, I've found a
kernel crasher in something as primitive as vfat upon mounting a tainted
floppy -- a looped directory was enough to kill Linux 2.0.30 and Win95.

Since then, security of filesystem drivers has vastly improved, but so has
complexity of filesystems.  FAT is _trivial_ compared to anything modern.
I see no way even a maintained filesystem to be 100% resilient against DoS
by mounting a crafted volume -- and there's a good chance there'll be
arbitrary code execution as well.  Unlike network code that's carefully
written to be secure, at considerable efficiency cost, no one really bothers
for this with filesystems.  And even if someone did, it takes just one buggy
filesystem -- Debian/Devuan kernels enable support for such dubious stuff as
hfs or qnx4.

I also can't recall ever connecting a "data" USB thingy to an Unix box --
and I have an USB stick and two SD readers on my desk right now; it's all
installer media, ARM SoC disks, etc.  Nothing for non-root to look at.

I don't think a regular user has any reason to mount a fancy filesystem.


-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Steve Litt]

On Sun, 9 Apr 2017 17:01:21 -0700
Rick Moen  wrote:

> Quoting Joachim Fahrner (j...@fahrner.name):
> 
> > Hi,
> > how can I get rid of libsystemd0? gvfs depends on it, and without
> > gvfs PCmanFM does not mount external usb drives.   
> 
> > Is there a way to user mount external drives without gvfs?  
> 
> My way of mounting external drives:
> 
> $ tail /var/log/dmesg   # Note the device name
> $ su -
> # mount /dev/sdXX /mnt
> # exit

I think I know why, but I'll ask you anyway. Why don't you just put
mount in /etc/sudoers and make it not require a password?
 
SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Rick Moen]

Quoting Joachim Fahrner (j...@fahrner.name):

> Hi,
> how can I get rid of libsystemd0? gvfs depends on it, and without
> gvfs PCmanFM does not mount external usb drives. 

> Is there a way to user mount external drives without gvfs?

My way of mounting external drives:

$ tail /var/log/dmesg   # Note the device name
$ su -
# mount /dev/sdXX /mnt
# exit

Worked twenty years ago, works the same today.


Looking for a graphical file manager?  I suggest bash in an xterm.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Steve Litt]

On Sun, 9 Apr 2017 22:39:28 +
Daniel Abrecht  wrote:

> On 04/09/2017 08:01 PM, Steve Litt wrote:
> > On Sun, 09 Apr 2017 08:24:15 +0200
> > Joachim Fahrner  wrote:  
> >> without gvfs PCmanFM does not mount external usb drives  
> >
> > Somewhere back in the archives I submitted a shellscript to
> > automatically mount thumb drives without a file manager.  
> 
> I think automatically mounting thumb drives is very different from
> mounting them when I klick on them in my file manager. Things like
> automatically mounting removable medias or even auto starting
> applications, I don't want that. What if I want to rescue a faulty
> thumb drives for example, automatically mounting it would could
> damage it even further. I think that Linux doesn't do or change things
> on it's own like Windows used to be a big strength of it.
> 
> Daniel Abrecht

Mounting them only on user demand would be even easier. Here's my
choosethumb.sh, which assists me to ask to mount a thumb drive:


=

#!/bin/sh

# Copyright (C) 2017 by Steve Litt
# Licensed with the Expat license:
#   http://directory.fsf.org/wiki/License:Expat

mountsfile=/tmp/mounts.tmp
mountdir=$HOME/media

usage(){
  echo
  echo 'USAGE: choosethumb.sh [-m|-u]'
  echo ' for mount and umount respectively'
  echo ' must have sudo rights to mount/umount'
  echo
  exit 9
}

listdevs(){
  readlink /dev/disk/by-id/*-part* | \
   awk -F/ '{print $NF}' | sort -u
}

listthumbs(){
  readlink /dev/disk/by-id/usb-*:?-part* | \
   awk -F/ '{print $NF}' | sort -u
}

handledevs(){
  while read thisdev; do
if grep $thisdev $mountsfile > /dev/null; then
  echo `grep $thisdev $mountsfile`
else
  echo $thisdev '   unmounted'
fi
  done
}

orgdir=`pwd`
cd $HOME

mount | grep ^/dev/sd | \
  sed -e 's+^/dev/++' -e 's+type.*++' > \
  $mountsfile


if test "$#" != "1"; then
  usage
elif test "$1" = "-m"; then
  mychoice=`listthumbs  | handledevs | sort -u | \
dmenu -l 20 -fn 10x20`
  resultt=$?
  myfcn=m
elif test "$1" = "-u"; then
  mychoice=`listthumbs  | handledevs | \
grep -v "unmounted" | sort -u | \
dmenu -l 20 -fn 10x20`
  resultt=$?
  myfcn=u
else
  usage
fi
  
if test "$resultt" = "0"; then
  trimchoice=`echo $mychoice | cut -f 1 -d " "`
  if test "$myfcn" = "m"; then
mkdir -p $mountdir/$trimchoice
if sudo mount /dev/$trimchoice $mountdir/$trimchoice; then
  echo "Mounted /dev/$trimchoice on $mountdir/$trimchoice"
else
  echo "Mount FAILED: /dev/$trimchoice on "
  echo "$mountdir/$trimchoice"
  exit 2
fi
  elif test "$myfcn" = "u"; then
if sudo umount /dev/$trimchoice; then
  echo -n "UnMounted /dev/$trimchoice away "
  echo "from $mountdir/$trimchoice"
else
  echo "Failed to unmount /dev/$trimchoice"
  echo "Check what is using it and try again."
  exit 3
fi
  else
echo "Internal argument error, call programmer, aborting."
exit 5
  fi
else
  if test "$myfcn" = "m"; then
echo 'User declined to mount.'
  else
echo 'User declined to unmount.'
  fi
  exit 1
fi
cd $ORGDIR
exit 0


=

Modify to suit your taste.

SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[fsmithred]

On 04/09/2017 02:24 AM, Joachim Fahrner wrote:
> Hi,
> how can I get rid of libsystemd0? gvfs depends on it, and without gvfs
> PCmanFM does not mount external usb drives. Is there a way to user mount
> external drives without gvfs?
> 
> Jochen
> 
> 

PCmanFM mounts external usb drives for me without libsystemd0 installed. I
guess it's using pmount, which is installed. What it does not seem to do
is un-mount the drive, even though it acts like it does. I had to run
'pumount ' to get rid of it.

There's also usbpmount, which I wrote for those of use who use Thunar and
don't want libsystemd0. It uses yad for a graphical front-end, and it does
not auto-mount. You have to make a couple of clicks for it to happen.
https://sourceforge.net/projects/refracta/files/Extras/

Steve says he wrote one, but I think he actually wrote two. One was less
than two months ago (see post "Thumb drive chooser" Feb 19). And one was
more than a few months ago.


fsmithred


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Daniel Abrecht]

On 04/09/2017 08:01 PM, Steve Litt wrote:
> On Sun, 09 Apr 2017 08:24:15 +0200
> Joachim Fahrner  wrote:
>> without gvfs PCmanFM does not mount external usb drives
>
> Somewhere back in the archives I submitted a shellscript to
> automatically mount thumb drives without a file manager.

I think automatically mounting thumb drives is very different from
mounting them when I klick on them in my file manager. Things like
automatically mounting removable medias or even auto starting
applications, I don't want that. What if I want to rescue a faulty
thumb drives for example, automatically mounting it would could
damage it even further. I think that Linux doesn't do or change things
on it's own like Windows used to be a big strength of it.

Daniel Abrecht





signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Steve Litt]

On Sun, 09 Apr 2017 08:24:15 +0200
Joachim Fahrner  wrote:

> Hi,
> how can I get rid of libsystemd0? gvfs depends on it, and without
> gvfs PCmanFM does not mount external usb drives. Is there a way to
> user mount external drives without gvfs?
> 
> Jochen

Somewhere back in the archives I submitted a shellscript to
automatically mount thumb drives without a file manager. Someone else
improved it dramatically.

Everyone: This is going to come up again and again to the extent that
maybe Devuan should offer this kind of script to everyone, kind of like
KatolaZ created a CLI-capable shellscript that replaced NetworkManager
and Wicd.

 
SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Hendrik Boom]

On Sun, Apr 09, 2017 at 12:58:27PM +0200, Joachim Fahrner wrote:
> 
> Thanks for that hint. SpaceFM in conjunction with udevil is great. So I can
> get rid of this ugly gvfs. gfvs is broken by design, because it creates a
> ~/.gvfs directory which is not accessible by root. So every backup tool
> fails when accessing this directory.
> 
> It is untypical for Unix systems that root cannot access everything on the
> local machine. I'm wondering how they achieve that, it should not be
> possible at all.

I don't know how gvfs does it, but it can be done with a user file system.
It happens all the time when I use sshfs.  An ssh file system allows only the 
user 
who mounted it to access it.  Since sshfs, once it gains control, can do as it 
pleases, if can simply refuse to allow opeations under whatever criteria are 
coded 
into it.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Joachim Fahrner]

Am 2017-04-09 10:43, schrieb Florian Zieboll:


I use spacefm. With some config-tweaking it is a perfect (and much more
flexible) replacement for pcmanfm and alike:


Thanks for that hint. SpaceFM in conjunction with udevil is great. So I 
can get rid of this ugly gvfs. gfvs is broken by design, because it 
creates a ~/.gvfs directory which is not accessible by root. So every 
backup tool fails when accessing this directory.


It is untypical for Unix systems that root cannot access everything on 
the local machine. I'm wondering how they achieve that, it should not be 
possible at all.


I feel more and more that the Gnome devs have no basic understanding of 
unix systems.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] gvfs depends on libsystemd0

[Florian Zieboll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 09 Apr 2017 08:24:15 +0200
Joachim Fahrner  wrote:

> Hi,
> how can I get rid of libsystemd0? gvfs depends on it, and without
> gvfs PCmanFM does not mount external usb drives. Is there a way to
> user mount external drives without gvfs?
> 
> Jochen



Hallo Jochen,

I use spacefm. With some config-tweaking it is a perfect (and much more
flexible) replacement for pcmanfm and alike:

https://ignorantguru.github.io/spacefm/ 

IIRC, there also was a WindowMaker dockapp, but I couldn't find it
right now on the fly. If you look for reverse dependencies of udevil,
udisks or pmount, you'll probably find some more suitable tools with a
GUI.

libre Grüße,

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY6fRBAAoJEO5FSXn+RB/WhUkQAKbmoEMpTFM8oirxoCKohQgF
dMUfI7D1xbHZsXrz+Tuo4BHbjJyr7H+FD9wZ37Aov+aqTeWqqCWD4iQ1Rhk2yiRz
hKMU5EiWjJI8dowEd/Z3Pliv8ZjtN2jjI7CLezNP1bl+25R20eREicwC3mR6sx3h
dq5OroKytukbGoC4sjT0z1qfNhP+t7D2yaEqVhli0mkCFVplkaUNY6vF+ZpaUYx/
mGtWEh/L48LmzFn/2nbrWbcr1QWbEdTVA5jMXdqAXAhMf3UQilP6Bf+rljz3Hr3z
x69NHQhcUyBJIS+IYf5q6vAOe3sX4J0AapfFX+bupsrVTzBy7cOQr+8PGDs70HX+
3gtPTlYM++G6boy5j8Z0Uw4DJCo5g9NYdUmqKwJ74sASpnZcr2AQ/iRP8CO/lAYE
LW8c6Vlur1cbZPfCVOZSpvRXrOg9vmJ5CzM/z9oMGcvt82ZEeeZ3rO3eepaxxb7r
RjcdGv8iRexvvZI03kYnoMNbKIEqha0jVwpgeKul+XIi+0390soJCJ2IwdMywxrn
KPsitsZDFEUkT/Ok/WK5vPGSRYaRtoxslrLSrqanMvWqQDmZfd982onomz1HePiG
6T2BwTZ22WY8faZJXvohvLSvvPj7iSXSld+2TzLgdzxIMj6H56FX5zAFtx1S7ye0
VpJa/nvNJFYwx4G+fQX7
=BviB
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng