on Tue, Dec 02, 2003 at 06:30:30PM -0500, Paul Morgan ([EMAIL PROTECTED]) wrote:
> On Tue, 02 Dec 2003 15:27:20 -0500, Paul Morgan wrote:
>
> >
> > Default debian install creates no usr/local directories, at least it never
> > has for me.
> >
>
> Sorry, I lied about this, I think it does create
On Tue, 02 Dec 2003 15:27:20 -0500, Paul Morgan wrote:
>
> Default debian install creates no usr/local directories, at least it never
> has for me.
>
Sorry, I lied about this, I think it does create a set of empty
directories.
> Also, default debian installation does *not* put cwd in root's p
On Mon, 01 Dec 2003 21:34:21 +, Geoff Bagley wrote:
>
>
> On an "owner-occupier" system you need a bit of system hygiene, and to
> keep one eye on the accepted F.H.S.
>
> Best regards.
>
> Geoff
Amen to that, Geoff.
--
paul
"Reports that say that something hasn't h
On Mon, 01 Dec 2003 21:08:34 +, Randy Orrison wrote:
> Paul Morgan wrote:
>> The key in any case is to protect your /usr/local... from anyone except
>> root writing to it, and also not to put current directory in root's path.
>
> Excellent idea. Too bad debian doesn't do that out of the box
scripsit Paul E Condon:
> For someone who already understands what PATH is and has well formed
> ideas as to how he wants to work, it is easy to change. Debian, or any
> other OS, would have a hard time stopping you. It so easy to change,
> for the skilled user, that it is hard to argue that it s
On Mon, Dec 01, 2003 at 01:36:55PM -0700, Thanasis Kinias wrote:
> scripsit Paul E Condon:
>
> > An OS should be configured to help a user avoid shooting himself in
> > the foot. To this end $HOME/bin should be at the *end* of the PATH.
> > This way, a new user who makes truly foolish name choise
> One of the things I thoroughly dislike about unices is that anybody and
> his mother who thinks he is able to write a program, think they have
> the god given right to bother a whole system with his fscked up s**t,
> ie. 'adjust' the whole environment for some particular program.
Once upon a
Paul Morgan wrote:
The key in any case is to protect your /usr/local... from anyone except
root writing to it, and also not to put current directory in root's path.
Excellent idea. Too bad debian doesn't do that out of the box.
/usr/local... doesn't exist so non-admins can put commands in there;
scripsit John Smith:
> > One good reason why that behaviour is evil is that I may want to install
> > custom versions of utils without messing with /bin or /usr/bin. That's
> > what /usr/local is for, after all.
>
> One of the things I thoroughly dislike about unices is that anybody
> and his mot
scripsit Paul E Condon:
> An OS should be configured to help a user avoid shooting himself in
> the foot. To this end $HOME/bin should be at the *end* of the PATH.
> This way, a new user who makes truly foolish name choises for his
> first few programs, is not cut off from critical parts of the O
On Mon, 2003-12-01 at 14:14, Vineet Kumar wrote:
> * Thanasis Kinias ([EMAIL PROTECTED]) [031201 11:03]:
> > BTW, if someone has compromised your system to the extent of being able
> > to put a trojaned passwd in /usr/local/bin, he can put it in /usr/bin,
> > too.
>
> Not necessarily. In order to
On Mon, Dec 01, 2003 at 12:37:48PM -0700, Thanasis Kinias wrote:
>
> Ja, if a user is competent to be building custom binaries, he or she
> should be able to add $HOME/bin to $PATH.
>
An OS should be configured to help a user avoid shooting himself in
the foot. To this end $HOME/bin should be at
> One good reason why that behaviour is evil is that I may want to install
> custom versions of utils without messing with /bin or /usr/bin. That's
> what /usr/local is for, after all.
One of the things I thoroughly dislike about unices is that anybody and
his mother who thinks he is able to wri
scripsit Paul Morgan:
> The key in any case is to protect your /usr/local... from anyone
> except root writing to it, and also not to put current directory in
> root's path. /usr/local... doesn't exist so non-admins can put
> commands in there; they should be putting them in somewhere in their
rc, didn't get a
>> > usable answer (can't find any use of /etc/login.defs).
>> >
>> >What is the rationale behind the PATH environment variable?
>> > Running woody I get
>> >
>> > /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/
On Mon, 2003-12-01 at 13:49, John Smith wrote:
> thanks for your remarks, they answer most of my questions,
> as did a thorough grep session on debian-policy, (thanks Paul). What
> I'm bothered with is that convenience takes precedence over security
> in this case. The example of an [evil/co
* Thanasis Kinias ([EMAIL PROTECTED]) [031201 11:03]:
> BTW, if someone has compromised your system to the extent of being able
> to put a trojaned passwd in /usr/local/bin, he can put it in /usr/bin,
> too.
Not necessarily. In order to put something in /usr/local/[s]bin, I just
need to get an ac
scripsit John Smith:
> Two other os-es that I'm thoroughly familiar with, Netware
> and Windows, insert for this exact reason the system paths before the
> local paths.
One good reason why that behaviour is evil is that I may want to install
custom versions of utils without messing with /bin o
etc/login.defs).
> >
> > What is the rationale behind the PATH environment variable?
> > Running woody I get
> >
> > /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
> >
> > as a normal user. As root I get
> >
> > /usr/local/sbin:/usr/l
on Sun, Nov 30, 2003 at 11:01:35PM +0100, John Smith ([EMAIL PROTECTED]) wrote:
> Hi All,
>
> checked google, asked this before on irc, didn't get a
> usable answer (can't find any use of /etc/login.defs).
>
> What is the rationale behind the PATH env
On Sun, 2003-11-30 at 17:01, John Smith wrote:
> Hi All,
>
> checked google, asked this before on irc, didn't get a
> usable answer (can't find any use of /etc/login.defs).
>
> What is the rationale behind the PATH environment variable?
> Running w
On Sun, 30 Nov 2003 23:01:35 +0100, John Smith wrote:
> Hi All,
>
> checked google, asked this before on irc, didn't get a
> usable answer (can't find any use of /etc/login.defs).
>
> What is the rationale behind the PATH environment variable?
> Runni
Hi All,
checked google, asked this before on irc, didn't get a
usable answer (can't find any use of /etc/login.defs).
What is the rationale behind the PATH environment variable?
Running woody I get
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
as a normal use
Viktor writes:
> pppconfig is not mentioned in the HOWTO, so it's obviously something
> Debian-specific.
It's only available in Debian, but it isn't really Debian-specific. The
way pppconfig sets up ppp is in line with the recommendations of the
upstream ppp maintainers.
> I had to modify the cr
John Hasler wrote:
> No. Each user would have his own chatscript in /etc/chatscripts and his
> own provider file in /etc/ppp/peers, with names like
> /etc/chatscripts/viktors-ppp and /etc/ppp/peers/viktors-ppp. The
> administrator would set these up using pppconfig in the normal fashion and
> the
I wrote:
> You can, however, give each user her own chatscript and put it in her group
> so that only she and root can read it.
Viktor Rosenfeld writes:
> So each user would have its own ppp-on-script, or better yet: A global
> ppp-on-script in /usr/local/bin, which uses $HOME to access the user's
John Hasler wrote:
> You can, however, give each user her own chatscript and put it in her group
> so that only she and root can read it.
So each user would have its own ppp-on-script, or better yet: A global
ppp-on-script in /usr/local/bin, which uses $HOME to access the user's
private chatscrip
John Hasler wrote:
> You can, however, give each user her own chatscript and put it in her group
> so that only she and root can read it.
So each user would have its own ppp-on-script, or better yet: A global
ppp-on-script in /usr/local/bin, which uses $HOME to access the user's
private chatscrip
Viktor writes:
> So root can give users on the system access to a PPP connection without
> letting them know, what the user name and password for that account is.
> Makes sense, although it's not aplicable to my situation, because I can't
> use PAP/CHAP and it wouldn't work with a chat script.
You
John Hasler wrote:
> Setuid root also makes it possible for the secrets
> files to be readable only by root, and for pppd to use the serial ports
> without the user having access to them. Pppd drops root privileges as soon
> as it doesn't need them.
So root can give users on the system access to
Viktor Rosenfeld writes:
> In the standard Debian (slink) install, the groups "dip" and "dialout"
> are created. dialout is used for dialout-devices (eg /dev/ttyS*,
> /dev/isdn*, ...) while dip is used for a couple of pppd files
> (/etc/ppp/*, /usr/sbin/pppd, ...).
Under the Debian system (it is
Hi there,
I recently configured PPP and everything works well. However, I do have
a question:
In the standard Debian (slink) install, the groups "dip" and "dialout"
are created.
dialout is used for dialout-devices (eg /dev/ttyS*, /dev/isdn*, ...)
while dip is used for a couple of pppd files (/et
32 matches
Mail list logo
