Russell Coker said:
> Which goes back to my previous question, what do you think it should
> have as the home directory then?
/etc/nohome, or something similar*. Somewhere where I can say "There should
be no files in that directory, because it's the home directory for disabled
accounts."
It sho
Russell Coker said:
> Which goes back to my previous question, what do you think it should
> have as the home directory then?
/etc/nohome, or something similar*. Somewhere where I can say "There should
be no files in that directory, because it's the home directory for disabled
accounts."
It sho
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> >> * A more important consideration is the location of "bin"'s $HOME.
>> >
>> > What's wrong with the current location?
>>
>> At the moment, nothing. Since writ
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> > There was a case of a buggy pam some time ago which let people login
>> > to
>> > accounts such as "man" and "bin". Changing the shell would have
>> > prevented
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> I guess what I'm saying is that there are just as many ways to get
>> access to UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the
>> /etc/passwd. As there are with "bin:x:2:2:bin:/bin:
Bernd Eckenfels said:
> Reading:
> In article <[EMAIL PROTECTED]> you
> wrote:
>> The /etc/passwd file does not control granting of priveledges[sic].
>
> and
>
>> It contains a map of UID <-> username <-> Primary GID
>
> is a contradiction on traditional unix, since the most powerful
> priveledge i
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> >> * A more important consideration is the location of "bin"'s $HOME.
>> >
>> > What's wrong with the current location?
>>
>> At the moment, nothing. Since writ
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> > There was a case of a buggy pam some time ago which let people login
>> > to
>> > accounts such as "man" and "bin". Changing the shell would have
>> > prevented
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> I guess what I'm saying is that there are just as many ways to get
>> access to UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the
>> /etc/passwd. As there are with "bin:x:2:2:bin:/bin:
Bernd Eckenfels said:
> Reading:
> In article <[EMAIL PROTECTED]> you
> wrote:
>> The /etc/passwd file does not control granting of priveledges[sic].
>
> and
>
>> It contains a map of UID <-> username <-> Primary GID
>
> is a contradiction on traditional unix, since the most powerful
> priveledge i
Bernd Eckenfels said:
> In article <[EMAIL PROTECTED]>
> you wrote:
>> Out of curiosity, what security benefit does a shell of /bin/false
>> grant, that say, an encrypted password of "NOLOGIN" (or equivalently
>> "*") does not grant?
>
> Two things, first it is more obvious from reading the passwor
Russell Coker said:
> On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
>> Russell Coker said:
>> > The idea of giving non-login accounts a shell of /bin/false is
>> > hardly new.
>>
>> Out of curiosity, what security benefit does a shell of /bin/false
>&
Bernd Eckenfels said:
> In article <[EMAIL PROTECTED]>
> you wrote:
>> Out of curiosity, what security benefit does a shell of /bin/false
>> grant, that say, an encrypted password of "NOLOGIN" (or equivalently
>> "*") does not grant?
>
> Two things, first it is more obvious from reading the passwor
Russell Coker said:
> On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
>> Russell Coker said:
>> > The idea of giving non-login accounts a shell of /bin/false is
>> > hardly new.
>>
>> Out of curiosity, what security benefit does a shell of /bin/false
>&
Russell Coker said:
> The idea of giving non-login accounts a shell of /bin/false is hardly
> new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of "NOLOGIN" (or equivalently "*") does not
grant?
In what circumstances would a process be
Russell Coker said:
> The idea of giving non-login accounts a shell of /bin/false is hardly
> new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of "NOLOGIN" (or equivalently "*") does not
grant?
In what circumstances would a process be
Jamie Heilman wrote:
> Joe Moore wrote:
>> As to your later message:
>> setgroups() and initgroups() are not necessary. Already UID telnetd
>> is able to write to /var/run/utmp because of its membership in GID
>> utmp.
>
> Huh?
Telnetd does not run as root.
Nick Boyce wrote:
> On Thu, 29 Aug 2002 08:37:15 -0600 (MDT), Joe Moore wrote:
>>Another option would be to create a group, for example called
>>"tcpwrap". Add
>>tcpwrap:x:150:telnetd, sshd, irc, identd
>>(This list is based on the users in /etc/passwd which a
Jamie Heilman wrote:
>> Can I change this around a bit to achieve my goal - maybe make a new
>> group called "foo" (say) and give that gid to in.telnetd and
>> hosts.allow ... ?
>
> Obscuring your libwrap/tcpd configuration from your local users, at the
> expense of allowing services to run as sep
> In output of 'w' command I saw something like that:
>
> --cut--
> root 7073 0.0 0.0 1240 636 ?S11:09 0:05
> in.telnetd: some.host.in.my.domain --cut--
>
> Correct address I replaced with some.host.in.my.domain.
> Is root is logging to this mashine by telnet ???
Maybe, bu
> In output of 'w' command I saw something like that:
>
> --cut--
> root 7073 0.0 0.0 1240 636 ?S11:09 0:05
> in.telnetd: some.host.in.my.domain --cut--
>
> Correct address I replaced with some.host.in.my.domain.
> Is root is logging to this mashine by telnet ???
Maybe, b
21 matches
Mail list logo
