>My question is: If it were really important to make sure the user could no
>longer access the system at all, why not just delete the account? Deleting the
>user does not >(necessarily) delete their data, so what's the use case for
>keeping the account at all in such a situation?
In my experien
>My objection here is roughly the same. /sbin/nologin does not mean
>"locked out", it's a non-shell that can serve as a shell. While there
>may be some value in chsh disallowing a change *from* /sbin/nologin to
>something else by the own user, it's not intended to block any access at
>all by a
>Why do people have to think that people are being 'stauch defenders'
>when they might just needed a clearer explanation?
Stephen, I've been striving to keep my comments technically focused.
That remark slipped below my own standards. I didn't mean it as a
personal jibe, just a slightly light hear
I was just reviewing this thread to date, and came across somebody asking:
> How is this a "critical...security hole"?
I'm wondering if perhaps some of the staunch defenders of the status quo
have missed the security hole?
One of the checks that chsh makes when running for an unprivileged user
i
Kevin Kofler wrote:
>I can confirm [that Debian doesn't list nologin in /etc/shells.
I've also been researching this.
1. I have checked all current versions of Debian: wheezy (old-stable),
jessie (stable), and stretch (testing).
2. Ubuntu follows suit. I have checked all supported LTS versions:
As a member of the "remove nologin from /etc/shells" faction, I have 2
technical reasons for my position. I don't think either of these points
have been addressed by the "leave it in" faction.
1. Certain programs use pam_shells to check access, but without requiring
that the shell is able to run c
>nologin is listed in /etc/shells since 2002 [1].
This seems like a extraordinary mistake, and I agree with Jonathan
Kamens' comment on the original ticket [1]. I note that his concerns
were never adequately answered; the only response was a hand-wavy "well
we did it and it doesn't seem to have br
As well as Fedora itself, we need to get the infrastructure IPv6 ready.
My company has developed an IPv6 health checker. Given a domain, it
tests its nameservers, webservers, and mailservers for IPv6 readiness.
Currently fedoraproject.org scores 4 out of 9, so there's some room for
improvement!
>dnf remove '*debuginfo*'.fc20.x86_64
>dnf remove '*debuginfo*.fc20.x86_64'
both mean exactly the same thing, of course.
Reindl you need to revise sh quoting rules (which are admittedly odd,
but this is a simple case).
Toby.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.
I've been using Free Software for a very long time, and contributing in
a small way for nearly 20 years. I even worked briefly for Cygnus in the
1990s, shortly before the Red Hat acquisition. I've been an enthusiastic
user of Fedora since... well, since long before it was called Fedora:
about Red H
10 matches
Mail list logo
