On 08/21/2013 08:22 PM, Miloslav Trmač wrote:
On Wed, Aug 21, 2013 at 8:45 PM, "Jóhann B. Guðmundsson"
<johannbg@xxxxxxxxx> wrote:
Now for those that are not familiar with our default using the short fqdn it
cuts the fqdn at the highest level domain as in the first "dot" so in the
sample case the login and command line promt is shown as "container01".
That scalability problem comes immediately apparent when you would create
the next container01 for the next second level domain like
container01.ackme.com you as an ISP would be hosting, it would be also
showing "container01" at the login and command line prompt just begging for
administrative mistake and headaches.
It's not obvious to me that optimizing the default setup for ISPs (who
have server management as their core business, and will likely do much
more customization to get a competitive edge) is a good idea, but I'll
defer to people who actually do such things with containers.
If people do not want our login and command promt default to fqdn of the
host we should move forward and default it to "pretty hostname" instead
of using the short hostname anyway.
The other issue I would like to get some comments on is that we default to
setting an empty root password which will allow administrators to log into
containers as root and set the root password as well as removing few line
from spin kickstarts as well being beneficial to the arm community.
* If the container is supposed to resemble an ordinary operating
system, with user accounts and ability to use it "from the outside"
(whether using the console or over the network), then it should also
not allow just anyone who knows the IP address to connect. (per
systemd-nspawn(1), --private-network is not default.)
You create an OS container and run other containers within it ( users,
system etc ).
* If the container only sandboxes a separate service, there shouldn't
be a login process (or, an user session, really) running inside in the
first place; the tools should just launch a shell (or other tool)
running within the container, with the authentication happening
outside the container.
So, "no".
No what?
And I think you are confusing here OS container with application
container these are two different container solutions.
we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place.
That's equivalent to saying that all passwords are security through
obscurity, and equally incorrect.
If I was not obvious enough the difference is only in time and if you
are trying to claim that users dont get cracked after installing fedora
of the dvd I can tell you here and now that it already has happened and
that user did not have the faintest idea that a) sshd was running and b)
someone was trying to "login" to his system he just choice to install
Gnome of relengs dvd because that instalment gave him more complete
desktop experience.
Lesson he learned from that experience never to use Fedora again.
Lesson we should have learned was for us deliver identical install and
usage experience of dvd as the "live" images give users.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
