Re: [Dng] NetworkManager alternative
"frank ernest" wrote: > Far from your experience and knowledge essentially i'm lurking. > But, i'm wondering why no one mentions ceni whcih in my experience > (as a user!) works fine. And even me, i was able to manage umts > sticks using ceni. I can't find the web site myself, maybe that's why. http://manual.aptosid.com/en/inet-ceni-en.htm http://ftp.uni-erlangen.de/mirrors/aptosid/debian/pool/main/c/ceni/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] User password emailed in plain text
Seriously? I support the removal of systemd (after wasting hours of my time on both it and pulseaudio), but emailing me my password in plain text is a seriously bad move. I think this will hurt the project. Please stop this happening. Regards David ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] User password emailed in plain text
On 30/12/2014 16:52, David Robinson wrote: > Please stop this happening. It would be helpful to know which service mailed you back a plain text password. AFAICT, GitLab does not mail back passwords upon registration. If you're talking about the mailing list itself then it's a well-known mailman (mis)feature and you should really use a randomly generated password (or let mailman generate it for you, that is). Regards, -- Matteo Panella signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] NetworkManager alternative
For links to ceni I get only two useful ones: http://manual.aptosid.com/en/inet-ceni-en.htm and http://www.mepis.org/docs/en/index.php?title=Ceni I can't seem to find source code. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] NetworkManager alternative
No, wait, you sent the link in a later message, thanks. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Packaging system
>> I've been reading about how there's a new packaging >> system planned, might I inquire about the ideas/goals >> behind it? >> > > Not that I've seen. Although I have certainly made a few discussions on > the topic. As far as I know, the present plan is to stay with Apt for at > least the first release. https://www.mail-archive.com/dng%40lists.dyne.org/msg00051.html And later messages suggested to me that this was the case. Perhaps I misunderstood. Thanks ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Gnome
On 29.12.2014 14:13, Richard wrote: > Yes. > And use a DE like Xfce for easier takeup. > Needless complexity is a trap to delay the Devuan project. IIRC, our primary goal is to bring back the original freedom of chioce, and therefore support non-systemd (or maybe non-freedesktop.*) setups, which Debian just dropped. But we'll also sit ontop of Debian (at least for Jessie). So I dont see any problem in releasing things when they're ready. Maybe in the first stage, we just should work as an "overlay" (like Gentoo folks understand that term - not sure whether just an *additional* repo will be enough for that or a complete mirror is required - perhaps somebody else here can clarify that). For now, I'd suggest doing a rolling release, and maybe fork off "stable" repos from time to time (which will only get bugfixes for already existing packages, but no further changes). Of course, we also should have an experimental/testing stage/repo where fresh things come in quickly - but still based on jessie (not entirely new packages). With that model, we IMHO dont need those long discussions anymore, if some things (eg. Gnome) get interesting enough for people, they will care about them. (for me, personally, Gnome is completely irrelevant - I'm more concerned w/ getting rid of things like polkit, dbus, etc). cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
Hi Jude,
One thing that matters most (for me), is that you're here, working on this,
with Devuan team. This is very important!
Also, when talking about eudev, we have this:
q: plans when udev becomes systemd-only ? (after kdbus merge):
https://github.com/gentoo/eudev/issues/95
I can see why ("the reasons / motivation") the distros all over the globe,
are being forced to use systemd / dbus (on servers!!), and udev is one of
those (biggest) reasons... Otherwise, if we have a high quality udev
replacement, then, who cares about systemd? With a drop-in replacement for
udev, we can easily kick systemd! I know that there are that logind thing,
the gnome drama and etc but, first things first. :-P
>From what I'm seeing, eudev might hit a dead-end, sooner or later, making
it harder and harder to build a systemd-free Linux distro. I mean, when
system-udev enforces systemd=PID1, then, sysvinit-core|upstart will be
dead. Right?!
Unless, eudev start walking on its own path (Feasible? Viable?)...
So, vdev (and the proposed alternatives, including plain static /dev),
seems the way to go in the long run, for a systemd-free Linux distribution.
The question that remains: which path is a "way to go"?!
1- build a new "udev", lets say, vdev? or;
2- stick with eudev and, "after kdbus got merged" (when systemd-udev
becomes useless without systemd = PID1), eudev will follow its own path,
forever...
If we stick with "2", then, I think that it worth putting huge efforts into
eudev, to make it a high quality piece of software. Including a big
crowdfunding campaign everywhere! Of course, if desirable.
Nevertheless, I'm must confess, I'm still divided... All of this work,
isn't a waste of time and effort? I mean, systemd seems to be making the
life easier for a lot of projects! Even Enlightenment devs (I'm there on
e-devel list) are talking about the huge benefits of systemd, that it will
make E-Development easier, for example, when using it with Wayland/DRM,
also, `enlightenment_start` binary will not be required anymore (when with
systemd), less code for E team to maintain, and etc... :-):-/
:-) +_+
So, are we going to succeed (yes, we can do this)? Or this is a waste? Lets
not lie to ourselves... I know we can build a systemd-free distro, I know
that... But, honestly, I like the ideas behind systemd (new VT code
(consoled), native multiseat support, CGroup Process that can not "scape"
systemd) but, its implementation / architecture creeps the heel outta me!
Also, the attitudes of systemd developers makes me sick. They have no
"social skills" and a terrible bug handling. And I don't like to be forced
to use this, or that. Choice is always important, but too many choices are
also a bad thing.
Cheers!
Thiago
On 30 December 2014 at 01:45, Jude Nelson wrote:
> Hi TJ,
>
> I totally agree. I'm creating vdev to be a replacement for udev in the
> long term, but it will need a *lot* of testing before I'm comfortable
> recommending it as the default device manager in *any* distribution.
>
> That said, I hope to have an alpha package in a few days. It will be able
> to run side-by-side with udev/eudev/mdev/static dev.
>
> Jude
> On Dec 29, 2014 3:10 PM, "T.J. Duchene" wrote:
>
>> If I might offer my two cents, I'm afraid that I must agree. Don't get
>> me wrong, the vdev proposal is quite interesting, but for the first
>> release, I believe the best route is to stick with building udev apart from
>> the systemd source tree. To do it any other way will probably cause
>> software issues that we do not presently have the developer resources to
>> solve - especially if we are already going to be busy trying to compile or
>> provide metadata for all the packages in Debian Jesse.
>>
>> On Fri, Dec 26, 2014 at 2:05 AM, dima wrote:
>>
>>>
>>> You can't just switch to vdev, because many packages depend on libudev.
>>> Only udev and eudev provide it.
>>>
>>> eudev is the only realistic option right now, because it's a drop-in
>>> replacement. Moreover, it's the only udev alternative with feature-parity.
>>>
>>> By the way, I'm not sure whether vdev is ready for the prime time.
>>>
>>> On Thu, 25 Dec 2014 22:26:49 -0500
>>> "Martinx - ジェームズ" wrote:
>>>
>>> > Guys,
>>> >
>>> > I'm wondering here about what to do with `udev`, which is `systemd` in
>>> > fact...
>>> >
>>> > What about this:
>>> >
>>> >
>>> > 1- Rename current `udev` package to `systemd-udev`;
>>> >
>>> > 2- Add `vdev`;
>>> >
>>> > 3- Add `eudev`;
>>> >
>>> > 4- Add `mdev`;
>>> >
>>> > 4- Create a new Metapackage called `udev`, that will Depends on `eudev
>>> |
>>> > vdev | mdev | systemd-udev`.
>>> >
>>> >
>>> > This will be very similar to the new `init` Metapackage on Jessie, that
>>> > Depends on `systemd-sysv | sysvinit-core | upstart`.
>>> >
>>> > What do you guys think?
>>> >
>>> > Also, I would like to know more about the quality of `eudev` and if it
>>> > worth keeping it, since `systemd` developers will remove its "netlink"
>>> >
Re: [Dng] Packaging system
From: frank ernest Sent: Tuesday, December 30, 2014 11:18 AM To: dng@lists.dyne.org https://www.mail-archive.com/dng%40lists.dyne.org/msg00051.html >And later messages suggested to me that this was the case. >Perhaps I misunderstood. Maybe there is. I’m hardly a source of information or a person making decisions. I just make comments.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Packaging system
On 30.12.2014 18:18, frank ernest wrote: > https://www.mail-archive.com/dng%40lists.dyne.org/msg00051.html > > And later messages suggested to me that this was the case. > Perhaps I misunderstood. I was talking about forking dpkg/apt in case they would introduce any dependency on systemd (which is quite improbable) cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Device management [WAS: system scriptinng language.]
On 29.12.2014 04:52, Jude Nelson wrote: > Hi Enrico, > > ACLs act as whitelists that additionally let vdev equivocate about > device nodes to different processes, based on the user, group, process > information (PID, inode, binary path, SHA256), and requested device > file. Let's work through a few examples. Sounds great. But one question left: can it also rename devices that way ? Suppose all sessions should see "their" devices as the same names, even they're actually different devices (eg. multi-seat) - is that already possible ? cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
You can't just switch to vdev, because many packages depend on libudev. Only udev and eudev provide it. eudev is the only realistic option right now, because it's a drop-in replacement. Moreover, it's the only udev alternative with feature-parity. By the way, I'm not sure whether vdev is ready for the prime time. On Thu, 25 Dec 2014 22:26:49 -0500 "Martinx - ジェームズ" wrote: > Guys, > > I'm wondering here about what to do with `udev`, which is `systemd` in > fact... > > What about this: > > > 1- Rename current `udev` package to `systemd-udev`; > > 2- Add `vdev`; > > 3- Add `eudev`; > > 4- Add `mdev`; > > 4- Create a new Metapackage called `udev`, that will Depends on `eudev | > vdev | mdev | systemd-udev`. > > > This will be very similar to the new `init` Metapackage on Jessie, that > Depends on `systemd-sysv | sysvinit-core | upstart`. > > What do you guys think? > > Also, I would like to know more about the quality of `eudev` and if it > worth keeping it, since `systemd` developers will remove its "netlink" > support (am I right)? Then, `systemd-udev` will depends on `systemd` as > PID1 in the future (through KDBUS, if I'm not wrong), making it very hard > to keep `eudev` up to date. Source: > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html > > I would like to evaluate `vdev` soon as possible. > > Best! > Thiago -- Dima Krasner pgpirFgHTtLwL.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
How many times do we have to suffer from receiving this identical email? dima, please turn the automation OFF! On Sat, 12/27/14, dima wrote: Subject: Re: [Dng] What to do with udev? Some ideas... To: dng@lists.dyne.org Date: Saturday, December 27, 2014, 4:43 AM You can't just switch to vdev, because many packages depend on libudev. Only udev and eudev provide it. eudev is the only realistic option right now, because it's a drop-in replacement. Moreover, it's the only udev alternative with feature-parity. By the way, I'm not sure whether vdev is ready for the prime time. On Thu, 25 Dec 2014 22:26:49 -0500 "Martinx - ジェームズ" wrote: > Guys, > > I'm wondering here about what to do with `udev`, which is `systemd` in > fact... > > What about this: > > > 1- Rename current `udev` package to `systemd-udev`; > > 2- Add `vdev`; > > 3- Add `eudev`; > > 4- Add `mdev`; > > 4- Create a new Metapackage called `udev`, that will Depends on `eudev | > vdev | mdev | systemd-udev`. > > > This will be very similar to the new `init` Metapackage on Jessie, that > Depends on `systemd-sysv | sysvinit-core | upstart`. > > What do you guys think? > > Also, I would like to know more about the quality of `eudev` and if it > worth keeping it, since `systemd` developers will remove its "netlink" > support (am I right)? Then, `systemd-udev` will depends on `systemd` as > PID1 in the future (through KDBUS, if I'm not wrong), making it very hard > to keep `eudev` up to date. Source: > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html > > I would like to evaluate `vdev` soon as possible. > > Best! > Thiago -- Dima Krasner -Inline Attachment Follows- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Device management [WAS: system scriptinng language.]
Hey Enrico, Although it looks simple on the surface, your question got at a wonderful, thought-provoking design decision (at least, it took me several hours to think of a good answer). The design question is, for a device filesystem that equivocates about inode information in order to control access to it, does the equivocation include changing the inode name? At first, I thought the answer was "yes" so vdev could support presenting different devices under the same name to different seats. But, after taking some time to think about the consequences for path resolution, security, and metadata consistency, I think the correct answer is "no, we should go with your original proposal of giving each session its own /dev." Here's why: while it is certainly possible to write a filesystem that claims that an inode has a different name depending on which process is asking, doing so would introduce a lot of non-trivial changes to the filesystem's semantics. Namely, it raises even more difficult design decisions, such as: * What happens if /dev/foo appears as /dev/bar to process A, and process A tries to mknod() /dev/foo? Should this fail as EEXIST (revealing to process A that the hidden device /dev/foo exists), or should it succeed? * If creating /dev/foo succeeds for process A, what happens to the "real" /dev/foo? What should process B see? * How are different "versions" of /dev/foo (if I went with supporting this) affected by ACLs? Is there a way to make vdev smart enough that ACLs *don't* need to specify which /dev/foo they affect? I could come up with satisfactory answers to these, given enough time, but it would take a non-trivial amount of re-engineering to implement them. Regardless of the answers, vdev would definitely be more difficult to use as a result, since users wouldn't be able to apply their knowledge of POSIX filesystems to reason about its behavior. A much more elegant solution would be to give each session its own /dev like you were originally saying--it would allow users to interact with different devices under the same name, while also preserving POSIX filesystem semantics. Thanks for being patient with me and helping me resolve this! -Jude On Tue, Dec 30, 2014 at 4:31 PM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > On 29.12.2014 04:52, Jude Nelson wrote: > > Hi Enrico, > > > > ACLs act as whitelists that additionally let vdev equivocate about > > device nodes to different processes, based on the user, group, process > > information (PID, inode, binary path, SHA256), and requested device > > file. Let's work through a few examples. > > > > Sounds great. > > But one question left: can it also rename devices that way ? > > Suppose all sessions should see "their" devices as the same names, > even they're actually different devices (eg. multi-seat) - is that > already possible ? > > cu > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
You can't just switch to vdev, because many packages depend on libudev. Only udev and eudev provide it. eudev is the only realistic option right now, because it's a drop-in replacement. Moreover, it's the only udev alternative with feature-parity. By the way, I'm not sure whether vdev is ready for the prime time. On Thu, 25 Dec 2014 22:26:49 -0500 "Martinx - ジェームズ" wrote: > Guys, > > I'm wondering here about what to do with `udev`, which is `systemd` in > fact... > > What about this: > > > 1- Rename current `udev` package to `systemd-udev`; > > 2- Add `vdev`; > > 3- Add `eudev`; > > 4- Add `mdev`; > > 4- Create a new Metapackage called `udev`, that will Depends on `eudev | > vdev | mdev | systemd-udev`. > > > This will be very similar to the new `init` Metapackage on Jessie, that > Depends on `systemd-sysv | sysvinit-core | upstart`. > > What do you guys think? > > Also, I would like to know more about the quality of `eudev` and if it > worth keeping it, since `systemd` developers will remove its "netlink" > support (am I right)? Then, `systemd-udev` will depends on `systemd` as > PID1 in the future (through KDBUS, if I'm not wrong), making it very hard > to keep `eudev` up to date. Source: > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html > > I would like to evaluate `vdev` soon as possible. > > Best! > Thiago -- Dima Krasner pgpd22VfY0QUb.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
For God's sake, why you keep posting the very same massage over and over again?! Or, is that a problem with our mail list? On 27 December 2014 at 12:22, dima wrote: > You can't just switch to vdev, because many packages depend on libudev. > Only udev and eudev provide it. > > eudev is the only realistic option right now, because it's a drop-in > replacement. Moreover, it's the only udev alternative with feature-parity. > > By the way, I'm not sure whether vdev is ready for the prime time. > > On Thu, 25 Dec 2014 22:26:49 -0500 > "Martinx - ジェームズ" wrote: > > > Guys, > > > > I'm wondering here about what to do with `udev`, which is `systemd` in > > fact... > > > > What about this: > > > > > > 1- Rename current `udev` package to `systemd-udev`; > > > > 2- Add `vdev`; > > > > 3- Add `eudev`; > > > > 4- Add `mdev`; > > > > 4- Create a new Metapackage called `udev`, that will Depends on `eudev | > > vdev | mdev | systemd-udev`. > > > > > > This will be very similar to the new `init` Metapackage on Jessie, that > > Depends on `systemd-sysv | sysvinit-core | upstart`. > > > > What do you guys think? > > > > Also, I would like to know more about the quality of `eudev` and if it > > worth keeping it, since `systemd` developers will remove its "netlink" > > support (am I right)? Then, `systemd-udev` will depends on `systemd` as > > PID1 in the future (through KDBUS, if I'm not wrong), making it very hard > > to keep `eudev` up to date. Source: > > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html > > > > I would like to evaluate `vdev` soon as possible. > > > > Best! > > Thiago > > > -- > Dima Krasner > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Dng Digest, Vol 3, Issue 139
Well, pulseaudio is not the best option but, really, 75% is a bug. I'm using it 0.1% with 3 pids in a 4GB ram system, so... Ubuntu 14 is not the best example for nothing, in addition, 14.04 is not systemd native, so report the bug to canonical about systemd and 14.04 nix\ 2014-12-26 0:15 GMT-03:00 : > Send Dng mailing list submissions to > dng@lists.dyne.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > or, via email, send a message with subject or body 'help' to > dng-requ...@lists.dyne.org > > You can reach the person managing the list at > dng-ow...@lists.dyne.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dng digest..." > > > Today's Topics: > >1. configuration management (Hendrik Boom) >2. Re: system scriptinng language. (Hendrik Boom) >3. Re: system scriptinng language. (Svante Signell) >4. Re: configuration management (Christoph Lechleitner) >5. Re: sugestion apulse as pulseaudio replcement (m_maass) >6. Re: configuration management (Alex 'AdUser' Z) >7. Re: sugestion apulse as pulseaudio replcement (Martinx - ?) > > > -- > > Message: 1 > Date: Thu, 25 Dec 2014 12:54:54 -0500 > From: Hendrik Boom > To: dng@lists.dyne.org > Subject: [Dng] configuration management > Message-ID: <20141225175454.ga28...@topoi.pooq.com> > Content-Type: text/plain; charset=us-ascii > > On installation, the configuration files (in /etc, of course; are there > others?) should all be checked into a revision management system, with > a > vendor branch (the upstream versions from devuan) and a local branch > (the versions as adated to local requirrements). Every time an upgrade > makes changes, the appropriate merges should take place. If changes > are too radical, the merge will fail, and manual intervantion should be > mandatory. Deferring the merge resolution whould be possible -- the > revision management system will hold all the details. > > Doing this will maximize transparency whe things get complicated, and > leaves the sysadmin the opportunity to back out of configuration changes > manually or make other necessary changes. > > -- hendrik > > > > -- > > Message: 2 > Date: Thu, 25 Dec 2014 13:00:19 -0500 > From: Hendrik Boom > To: dng@lists.dyne.org > Subject: Re: [Dng] system scriptinng language. > Message-ID: <20141225180018.gb28...@topoi.pooq.com> > Content-Type: text/plain; charset=us-ascii > > On Wed, Dec 24, 2014 at 12:44:26AM -0500, Jude Nelson wrote: > > Hi T.J., sorry this is late--this thread got lost in my inbox. > > > > Thank you for your feedback regarding GPLv3. > > The *big* problem with GPLv3 is that it is incompatible with GPLv2. > It *is* compatible with GPL2+, but there is a lot of software that is > licenced GPL2 without the "or any later version" clause. > > This may, of course, be considered a problem with GPL2, but in the > present software ecology it will make GPL3 code harder to adopt. > > I will continue to licence any of my GPL software as GPL2+. > > -- hendrik > > > -- > > Message: 3 > Date: Thu, 25 Dec 2014 20:11:28 +0100 > From: Svante Signell > To: Hendrik Boom > Cc: dng@lists.dyne.org > Subject: Re: [Dng] system scriptinng language. > Message-ID: <1419534688.2810.8.ca...@gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 2014-12-25 at 13:00 -0500, Hendrik Boom wrote: > > On Wed, Dec 24, 2014 at 12:44:26AM -0500, Jude Nelson wrote: > > > Hi T.J., sorry this is late--this thread got lost in my inbox. > > > > > > Thank you for your feedback regarding GPLv3. > > > > The *big* problem with GPLv3 is that it is incompatible with GPLv2. > > It *is* compatible with GPL2+, but there is a lot of software that is > > licenced GPL2 without the "or any later version" clause. > > > > This may, of course, be considered a problem with GPL2, but in the > > present software ecology it will make GPL3 code harder to adopt. > > > > I will continue to licence any of my GPL software as GPL2+. > > The best would be to use GPL3+ to avoid tivoization. In case you want to > enable commercial use (modifications might not be given back) you can > dual license it, e.g. adding X11 (wrongly MIT) or 2- or 3-clause BSD. > See https://www.gnu.org/licenses/license-list.html > > > > -- > > Message: 4 > Date: Thu, 25 Dec 2014 20:29:32 +0100 > From: Christoph Lechleitner > To: Hendrik Boom ,dng@lists.dyne.org > Subject: Re: [Dng] configuration management > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > Am 25. Dezember 2014 18:54:54 MEZ, schrieb Hendrik Boom < > hend...@topoi.pooq.com>: > >On installation, the configuration files (in /etc, of course; are there > > > >others?) should all be checked into a revision management system, with > >a > >v
Re: [Dng] Device management [WAS: system scriptinng language.]
On Sun, Dec 28, 2014 at 10:52:38PM -0500, Jude Nelson wrote: > Here's a more practical example that hides /dev/input/* and /dev/dri/* from > every program except the X server (installed to /usr/bin/X): > > [vdev-acl] > bin=/usr/bin/X > paths=input/.*|dri/.* > setmode=0666 This seems broken to me... as in, the very idea you can trust a process because of its executable will give people a false sense of security. If a process runs with your uid, you can have it do anything you do want by a number of methods. You can ptrace it, LD_PRELOAD, use a ld of your own, etc. The only way to secure this is to use setuid, but then, you already have a better way selector to build the ACL on. Thus, I think you'd be better off without bin= stanzas. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] User password emailed in plain text
On Tue, Dec 30, 2014 at 03:52:39PM +, David Robinson wrote: > Seriously? > > I support the removal of systemd (after wasting hours of my time on both it > and pulseaudio), but emailing me my password in plain text is a seriously > bad move. I think this will hurt the project. > > Please stop this happening. > > Regards > > David You can ( and should ) change it from the web interface. Also, please open a bug report to gitlab developers about that. -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Device management [WAS: system scriptinng language.]
Hi Adam, Good catch! The class of user-initiated runtime program alterations (ptrace, LD_PRELOAD, LD_LIBRARY_PATH, different ld, etc) had slipped my mind. This is why I'm having the conversation on vdev's core features *before* the first alpha release, so design problems like this will get caught early :) I think setuid combined with vdev presents an interesting possibility: what if we changed X from setuid-root to setuid-daemon (or setuid-nobody, or whatever), and used a variant of the above stanza to grant it access to the privileged device nodes it needs? This would allow X to run as a less-privileged user than even the user that started it, while ensuring that it can access the necessary device files. So, the setup would become as follows: $ ls -l /usr/bin/X -rwsr-sr-x 1 daemon daemon 10104 Apr 1 2014 /usr/bin/X $ cat /etc/vdev/acls/X11.acl [vdev-acl] uid=daemon gid=daemon bin=/usr/bin/X paths=input/.*|dri/.* setmode=0666 In the absence of any ACLs that add permissions for /dev/dri/* and /dev/input/*, this vdev-acl stanza would ensure that only a process running as user daemon and group daemon whose binary is located at /usr/bin/X will see /dev/dri/* and /dev/input/* with permission bits 0666. You could (should) take additional filtering measures, such as adding "pidlist=cat /paths/to/X11/pid/files" to ensure that only the running X servers that have written their PID files already will see /dev/dri/* and /dev/input/* as read/write. DISCLAIMER: I have *not* tested this yet, but it should work so long as the only reason X otherwise needs to run as root is because the device nodes under /dev/input/ and /dev/dri/ are necessarily unreadable and unwritable for users outside the root user and input and video groups (respectively). It is my understanding that the advent of KMS already allows X to run without privileges as long as it can access the right device files (the problem vdev solves), but for multi-user systems the very same device files must be inaccessible to unprivileged users because they expose input and graphics data from other users' graphical sessions. Please correct me if I'm wrong :) -Jude On Wed, Dec 31, 2014 at 12:35 AM, Adam Borowski wrote: > On Sun, Dec 28, 2014 at 10:52:38PM -0500, Jude Nelson wrote: > > Here's a more practical example that hides /dev/input/* and /dev/dri/* > from > > every program except the X server (installed to /usr/bin/X): > > > > [vdev-acl] > > bin=/usr/bin/X > > paths=input/.*|dri/.* > > setmode=0666 > > This seems broken to me... as in, the very idea you can trust a process > because of its executable will give people a false sense of security. > > If a process runs with your uid, you can have it do anything you do want > by a number of methods. You can ptrace it, LD_PRELOAD, use a ld of your > own, etc. > > The only way to secure this is to use setuid, but then, you already have > a better way selector to build the ACL on. > > Thus, I think you'd be better off without bin= stanzas. > > -- > // If you believe in so-called "intellectual property", please immediately > // cease using counterfeit alphabets. Instead, contact the nearest temple > // of Amon, whose priests will provide you with scribal services for all > // your writing needs, for Reasonable and Non-Discriminatory prices. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
