On Thu, Mar 30, 2006 at 10:42:15AM -0500, [EMAIL PROTECTED] wrote:
> On Thu, Mar 30, 2006 at 10:03:06AM -0500, Andrew Cady wrote:
> >
> > Apparently the BSD folks decided in retrospect that mixing binaries with
> > configuration was a bad idea. But why not put them in /bin? It may
> > well have
On Thu, Mar 30, 2006 at 10:03:06AM -0500, Andrew Cady wrote:
>
> Apparently the BSD folks decided in retrospect that mixing binaries with
> configuration was a bad idea. But why not put them in /bin? It may
> well have been performance reasons; that also seems to have been the
> original reason
On Thu, Mar 30, 2006 at 04:13:52PM +0100, George Borisov wrote:
> Andrew Cady wrote:
> >
> > A little research reveals that the original AT&T Unix contained no
> > /sbin; however, the traditional contents of /sbin were present in /etc,
> > mixed with configuration files. 4.3BSD placed these files
Andrew Cady wrote:
>
> A little research reveals that the original AT&T Unix contained no
> /sbin; however, the traditional contents of /sbin were present in /etc,
> mixed with configuration files. 4.3BSD placed these files in /etc also,
> but 4.4BSD moved them to /sbin, reserving /etc for configu
On Sun, Mar 26, 2006 at 02:32:51PM -0500, Kevin Mark wrote:
> On Sun, Mar 26, 2006 at 03:22:06AM -0500, Andrew Cady wrote:
>
> > The only reasons for having a separate /sbin are historical, and even
> > then they are unclear. They certainly have nothing to do with security,
> > which is provided b
In linux.debian.user, gene.heskett wrote:
>
> I have a silly question though, why does the user need access to
> ifconfig? If the admin is doing his job, it seems that the network
On some (many?) boxes, the user == the administrator, just not logged
in as root. Not everyone has the privileg
Gene Heskett wrote:
On Sunday 26 March 2006 02:16, Matthew R. Dempsky wrote:
On Sun, Mar 26, 2006 at 12:46:14AM -0500, Gene Heskett wrote:
Giving everybody access to ifconfig and its ilk sure sounds like a
big security hole to me.
That's ridiculous. If adding ifconfig to your users' PATH i
On Sun, Mar 26, 2006 at 03:22:06AM -0500, Andrew Cady wrote:
> On Sun, Mar 26, 2006 at 02:39:51AM -0500, Gene Heskett wrote:
> >
> > IMO ifconfig is a system function, and the normal user has no need
> > for access to it, none, nada, zip. As the admin, the admin should be
> > responsible for that,
On Sun, Mar 26, 2006 at 02:39:51AM -0500, Gene Heskett wrote:
> On Sunday 26 March 2006 02:16, Matthew R. Dempsky wrote:
> >On Sun, Mar 26, 2006 at 12:46:14AM -0500, Gene Heskett wrote:
> >> Giving everybody access to ifconfig and its ilk sure sounds like a
> >> big security hole to me.
> >
> >That
On Sun, Mar 26, 2006 at 02:39:51AM -0500, Gene Heskett wrote:
>
> IMO ifconfig is a system function, and the normal user has no need
> for access to it, none, nada, zip. As the admin, the admin should be
> responsible for that, with those configs locked down for normal users.
>
> Heck, I'm using t
On Sunday 26 March 2006 02:16, Matthew R. Dempsky wrote:
>On Sun, Mar 26, 2006 at 12:46:14AM -0500, Gene Heskett wrote:
>> Giving everybody access to ifconfig and its ilk sure sounds like a
>> big security hole to me.
>
>That's ridiculous. If adding ifconfig to your users' PATH is a
> security con
On Sun, Mar 26, 2006 at 12:46:14AM -0500, Gene Heskett wrote:
> Giving everybody access to ifconfig and its ilk sure sounds like a big
> security hole to me.
That's ridiculous. If adding ifconfig to your users' PATH is a security
concern, your system is already at risk.
--
To UNSUBSCRIBE, em
On Sunday 26 March 2006 00:26, Sumo Wrestler (or just ate too much)
wrote:
>S. Keeling wrote:
>> [...]
>> And it's really annoying on every install to have to fix user's
>> PATHs adding /sbin so they can run ifconfig.
>> [...]
>
>Create a link in /usr/local/bin to ifconfig.
I have a silly questio
S. Keeling wrote:
[...]
And it's really annoying on every install to have to fix user's PATHs
adding /sbin so they can run ifconfig.
[...]
Create a link in /usr/local/bin to ifconfig.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PR
In linux.debian.user, you wrote:
> /bin and /sbin are binary and system binary.. /bin has utilties that all
> users can run and /sbin contains system utilities that usually only
> superusers can run.
And it's really annoying on every install to have to fix user's PATHs
adding /sbin so they can
/bin and /sbin are binary and system binary.. /bin has utilties that all
users can run and /sbin contains system utilities that usually only
superusers can run. /initrd holds scripts that execute for each
runlevel you enter and other boot type stuff..
Jeff
--
To UNSUBSCRIBE, email to [EMAI
Hello,
[EMAIL PROTECTED] (Michel Verdier) wrote:
> Jiri Baum <[EMAIL PROTECTED]> writes:
>
> > If you find a Debian package that has a config in /usr, it's a bug,
> > because FSSTND compliance is mandated by the Policy.
>
> What about /usr/local/etc ?
That's still a bug - packages may not put a
Jiri Baum <[EMAIL PROTECTED]> writes:
> If you find a Debian package that has a config in /usr, it's a bug, because
> FSSTND compliance is mandated by the Policy.
What about /usr/local/etc ?
--
o-o
[EMAIL PROTECTED] (Michel Verdier)
http://www.chez.com/mverdier
Hello,
> -> the /usr is the main area comparable to WINDOWS PROGRAMMS,
>
> it contains programs, sometimes configs, docs etc etc
^^^
I thought /usr is not allowed to contain configs?
Configs should go into /etc, /var, the user's home directory or the curr
Hello,
> Please help me for the right understanding:
I think you have it almost right...
> the /root contains only the kernel and the device drivers,
Actually, that's just "/". It's called the root directory, but it's not
actually under /root. (/root is the administrator's working area.)
>
On Thu, 3 Dec 1998, Michael Wahl wrote:
>
> Please help me for the right understanding:
> the /root contains only the kernel and the device drivers,
> the /home is the working area / space for the user (with space for
> store of their own data?),
> the /usr is the main area comparab
-> Please help me for the right understanding:
-> the /root contains only the kernel and the device drivers,
nope; /root is home directory for user root (privileged user, admin)
/boot contains boot files - kerneli image etc;
modules are in /lib/modules/{kernel version/*
-> the /home is the w
Hello,
Please help me for the right understanding:
the /root contains only the kernel and the device drivers,
the /home is the working area / space for the user (with space for
store of their own data?),
the /usr is the main area comparable to WINDOWS PROGRAMMS,
/var for printer, m
23 matches
Mail list logo
