quot;nologin" to see whether
there is a setup script that adds /sbin/nologin to /etc/shells and found
nothing [6].) So, we might think the makers of nologin either didn't want
to include it or made a mistake. Since the current OpenBSD still doesn't
include /sbin/nologin in /etc/shells
On Fri, Oct 7, 2016 at 8:03 AM, Björn Persson wrote:
> Andrew Toskin wrote:
>> 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 fo
Andrew Toskin wrote:
> 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?
The files
Once upon a time, Andrew Toskin said:
> But now I'm sorta curious about the opposite situation: What's the use case
> for blocking a user from accessing their account, rather than just deleting
> the account altogether?
There are lots of reasons. For example, if someone is paying for an
accoun
>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
Er, let me clarify: Much of the discussion here, as I see it, has been about
how to preserve a user account, but block user access to that account.
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? Deletin
We've discussed how and whether it's best practice to disallow a user from
logging into an account they previously had access to.
But now I'm sorta curious about the opposite situation: What's the use case for
blocking a user from accessing their account, rather than just deleting the
account a
On Tue, Oct 04, 2016 at 07:33:40PM -, Toby Goodwin wrote:
> 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 hearted way of characterizing one
> side of the debate. I a
>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
On 10/3/2016 3:02 PM, Stephen John Smoogen wrote:
On 3 October 2016 at 16:53, Toby Goodwin wrote:
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
On Tue, Oct 04, 2016 at 03:46:01PM +0200, Ondřej Vašík wrote:
> I don't think we should change this in released Fedoras ( I don't think
> this is critical security hole, when you have access to local shell, it
> is usually enough anyway ;) ), but adjustment in Rawhide seems
> reasonable.
> Any obje
Debian
> developer [4]: "The point of having a shell that's not in /etc/shells
> isn't that you can't use it to log in, but that it's not a normal
> shell and that users with that shell set can't change it to something
> else. Adding nologin to /etc/shells
On Fri, Sep 30, 2016 at 5:16 AM, Toby Goodwin wrote:
> 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.
[...]
>
> 2. Can anyone provide further deta
On 3 October 2016 at 16:53, Toby Goodwin wrote:
> 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?
>
Why do people
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:
Jakub Svoboda wrote:
> - Debian doesn't list nologin in /etc/shells.
I can confirm this. (I checked it on a Debian system.) And thus, the
argument that "this is just the Unix way and how it has always been" is not
valid.
Kevin Kofler
___
devel
On Fri, September 30, 2016 3:16 am, Toby Goodwin wrote:
> 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 ch
On Sep 30, 2016 05:17, "Toby Goodwin" wrote:
>
> 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 acce
On 30 September 2016 at 12:07, Stephen John Smoogen wrote:
> On 30 September 2016 at 02:25, Thomas Moschny
> wrote:
>> 2016-09-29 16:58 GMT+02:00 Stephen John Smoogen :
>>> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46
>>
>> This is titled
>> "All she
On 30 September 2016 at 02:25, Thomas Moschny wrote:
> 2016-09-29 16:58 GMT+02:00 Stephen John Smoogen :
>> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46
>
> This is titled
> "All shells referenced in /etc/passwd must be listed in the
> /etc/shells file
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
2016-09-29 16:58 GMT+02:00 Stephen John Smoogen :
> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46
This is titled
"All shells referenced in /etc/passwd must be listed in the
/etc/shells file, except any shells specified for the purpose of
preventing logi
On Thu, Sep 29, 2016 at 9:58 PM, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>> Well that boat sailed in 2001... so have you been removing it from
>> your /etc/shells in the last 15 years?
>
> No, because I was not aware that Fedora had been shipping with this security
> hole for 15 years! O
On 9/29/2016 5:55 PM, Kevin Kofler wrote:
Nobody should ever add this at all. And most definitely not Fedora.
The behavior the original poster pointed out:
| - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the
| default shell) succeeds with /bin/bash if auth is successful [
On 29 September 2016 at 21:58, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>> Well that boat sailed in 2001... so have you been removing it from
>> your /etc/shells in the last 15 years?
>
> No, because I was not aware that Fedora had been shipping with this security
> hole for 15 years! Of
Stephen John Smoogen wrote:
> Well that boat sailed in 2001... so have you been removing it from
> your /etc/shells in the last 15 years?
No, because I was not aware that Fedora had been shipping with this security
hole for 15 years! Of course I immediately fixed it upon reading this
thread.
On 29 September 2016 at 20:55, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>> One of the reasons for it to be in /etc/shells was that various audit
>> systems failed an OS if it wasn't. [Various government and bank
>> security audit tools have rules like
>> https://www.stigviewer.com/stig/vm
Stephen John Smoogen wrote:
> One of the reasons for it to be in /etc/shells was that various audit
> systems failed an OS if it wasn't. [Various government and bank
> security audit tools have rules like
> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46
> ]
On 29 September 2016 at 04:54, Toby Goodwin wrote:
>>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 wa
>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
Hello,
I'm linking another bugzilla [1] related to this, this one is against
shells(5) man page.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1218302
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@
would be very likely to open security vulnerabilities, and I
will not do it."
It seems as though /sbin/nologin is listed in /etc/shells as a workaround
to some issues without even documenting it in the man pages. These issues
are not important enough for those distributions and OSes that
34 matches
Mail list logo
