FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Desktop

 
 
LinkBack Thread Tools
 
Old 03-27-2008, 08:07 PM
Benny Amorsen
 
Default few ideas how to make fedora better as a desktop

"Shawn Starr" <sstarr@platform.com> writes:

Top posting kills kittens.

> Well, if you did a ldd on a unix box you'd notice binaries in /sbin were staticly built.

Depends how you define Unix then. I don't have any actual Unix
certified OS's around, but Fedora certainly doesn't link everything in
/sbin statically.

My favourite:

$ ldd /sbin/dump.static
linux-gate.so.1 => (0x00110000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x00ca6000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00d0d000)
libz.so.1 => /lib/libz.so.1 (0x0058e000)
libbz2.so.1 => /lib/libbz2.so.1 (0x00cfa000)
libblkid.so.1 => /lib/libblkid.so.1 (0x00c66000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00c8a000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x0060e000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00336000)
libsepol.so.1 => /lib/libsepol.so.1 (0x00765000)
libc.so.6 => /lib/libc.so.6 (0x003e6000)
libdl.so.2 => /lib/libdl.so.2 (0x0056c000)
/lib/ld-linux.so.2 (0x003c7000)

(Yes that's cheating, /sbin/dump.static is a symlink. But still
funny.)


/Benny


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-27-2008, 08:20 PM
"Shawn Starr"
 
Default few ideas how to make fedora better as a desktop

Well, in that case any of those .static symlinks should be properly built static in their respective .spec/RPMs they reside from. Maybe another item for the Sbin project?

> -----Original Message-----
> From: fedora-devel-list-bounces@redhat.com
> [mailto:fedora-devel-list-bounces@redhat.com]On Behalf Of
> Benny Amorsen
> Sent: Thursday, March 27, 2008 5:07 PM
> To: fedora-devel-list@redhat.com
> Subject: Re: few ideas how to make fedora better as a desktop
>
>
> "Shawn Starr" <sstarr@platform.com> writes:
>
> Top posting kills kittens.
>
> > Well, if you did a ldd on a unix box you'd notice binaries
> in /sbin were staticly built.
>
> Depends how you define Unix then. I don't have any actual Unix
> certified OS's around, but Fedora certainly doesn't link everything in
> /sbin statically.
>
> My favourite:
>
> $ ldd /sbin/dump.static
> linux-gate.so.1 => (0x00110000)
> libext2fs.so.2 => /lib/libext2fs.so.2 (0x00ca6000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00d0d000)
> libz.so.1 => /lib/libz.so.1 (0x0058e000)
> libbz2.so.1 => /lib/libbz2.so.1 (0x00cfa000)
> libblkid.so.1 => /lib/libblkid.so.1 (0x00c66000)
> libuuid.so.1 => /lib/libuuid.so.1 (0x00c8a000)
> libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x0060e000)
> libselinux.so.1 => /lib/libselinux.so.1 (0x00336000)
> libsepol.so.1 => /lib/libsepol.so.1 (0x00765000)
> libc.so.6 => /lib/libc.so.6 (0x003e6000)
> libdl.so.2 => /lib/libdl.so.2 (0x0056c000)
> /lib/ld-linux.so.2 (0x003c7000)
>
> (Yes that's cheating, /sbin/dump.static is a symlink. But still
> funny.)
>
>
> /Benny
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-27-2008, 08:45 PM
Andrew Farris
 
Default few ideas how to make fedora better as a desktop

Jeff Spaleta wrote:

On Thu, Mar 27, 2008 at 12:32 PM, Chris Adams <cmadams@hiwaay.net> wrote:


bin vs. sbin is not at all a security measure, since users can already
run things in sbin just by using the full path (or adding the sbin dirs
to their PATH).


By default its not... but on a multiuser system you can restrict access the
sbin directories
limiting access.. in a way that package updates don't revert your changes.

If our intent is to expose these binaries, and encourage a culture where
normal users can expect access to these paths and the binaries in them, then
it would make some sense to be sure we aren't creating an additional admin
burden that forces admins to re-restrict access to paths that Fedora users
come to expect.... for the sake of limiting access to a handle full of
setuid'd binaries.


Yes it should be carefully considered, but if the administrator has restricted access via
perms or acls to those directories, then it will not matter if the user has them included
in their path. With access restrictions in place, a normal user typing ifconfig vs
/sbin/ifconfig will get the same result -- denied access. On a system where the access
restrictions are not in place the result would differ. So if an administrator has
restricted them or not should not effect how they behave (whether suid or not); they have
access or they don't. The security issue is there right now for suid binaries and the
changes discussed so far here should not effect that security issue one way or the other.


--
Andrew Farris <lordmorgul@gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-27-2008, 08:46 PM
"Stephen John Smoogen"
 
Default few ideas how to make fedora better as a desktop

On Thu, Mar 27, 2008 at 2:54 PM, Alan Cox <alan@redhat.com> wrote:
> On Thu, Mar 27, 2008 at 02:21:13PM -0500, Les Mikesell wrote:
> > OK, when tiny disk drives cost $10,000 and had to come from the same
> > vendor as the CPU, and you couldn't boot from anything else there was a
> > reason to have /bin and maybe /sbin separate. But that was in some
> > other century.
>
> Go back that far and you are talking about bin versus usr.
>
> Historically bin was on the fast fixed head disk and usr/bin on the moving
> head disk.
>

By the time I got to Unix on a Vax750.. /bin was on our first 40 MB
washing machine, /usr was on our second 40MB washing machine, and
/usr/local was on our third one... and you hoped that nobody set up
reads and writes to get them to pull apart.

> sbin is a SunOS era invention that exists essentially because they didn't
> have a nice mechanism to boot a box and recover it if you broke the shared
> libraries (and they were quite fragile)
>

Putting /usr on a seperate partition in 4.0 kills kittens... [and I
think the same with 3]


--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-28-2008, 04:47 AM
Andrew Farris
 
Default few ideas how to make fedora better as a desktop

Ralf Corsepius wrote:

On Wed, 2008-03-26 at 11:40 -0500, Les Mikesell wrote:

Whatever purpose someone thought the s- versions might have ever served
flies out the window when the the administrator and the only user are
one and the same person who is just confused by sometimes having
commands work and sometimes not.

This proposal is in the same class of proposals proposing to abandon
"user accounts" and/or to use "root only".


No it is not. There are absolutely no security considerations *right now* for
whether a normal user has /*/sbin in their path or not. This has nothing
whatsoever to do with access permission or authorization for actions those
binaries may attempt to make. Changing to root only definitely does.


--
Andrew Farris <lordmorgul@gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-28-2008, 06:03 AM
Ralf Corsepius
 
Default few ideas how to make fedora better as a desktop

On Thu, 2008-03-27 at 13:40 -0400, David Mansfield wrote:
> On Thu, 2008-03-27 at 12:27 -0500, Les Mikesell wrote:
> > Ralf Corsepius wrote:
> > >
> > > The last part of your sentence is the key. /sbin and /usr/sbin exist to
> > > keep tools out of ordinary users' PATH.
> > >
> >
> > Which made sense when every machine was expected to have an
> > administrator to do the complicated stuff for you,
Not at all. These things are supposed to be setup "automatically".

Ordinary users are not supposed to look into them rsp. should not even
have to know about them - Unless ... they want to explicitly have them,
i.e. to act as maintainers.

> > but fedora doesn't ship one.


> Or maybe it existed to keep path search times down for users who didn't
> need those extra programs there...
Yep, this also had been a point in the past when disk access had been
expensive, rsp. to work around filesystem limitations.

Nowadays it's simply a usability aspect: Don't molest clueless users
with tools in their $PATH they won't need rsp. which aren't useful to
them.

> Of course, we now have 3123 programs in /usr/bin on my F8 system.
And ...?

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-28-2008, 07:16 AM
Ralf Corsepius
 
Default few ideas how to make fedora better as a desktop

On Thu, 2008-03-27 at 22:47 -0700, Andrew Farris wrote:
> Ralf Corsepius wrote:
> > On Wed, 2008-03-26 at 11:40 -0500, Les Mikesell wrote:
> >> Whatever purpose someone thought the s- versions might have ever served
> >> flies out the window when the the administrator and the only user are
> >> one and the same person who is just confused by sometimes having
> >> commands work and sometimes not.
> > This proposal is in the same class of proposals proposing to abandon
> > "user accounts" and/or to use "root only".
>
> No it is not. There are absolutely no security considerations *right now* for
> whether a normal user has /*/sbin in their path or not.

Correct, security is not the point. The point is *usability*

It's in the same lane as
"Who needs root, gid/uids when I am the only user on a system?

> This has nothing
> whatsoever to do with access permission or authorization for actions those
> binaries may attempt to make. Changing to root only definitely does.
That's not my rationale.

IMO, this proposal is yet the n-th manifestation of Fedora going down
the drain - Frankly speaking, to me this proposal is such kind of
absurd, I can only turn away in disgust.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-28-2008, 08:44 AM
Nils Philippsen
 
Default few ideas how to make fedora better as a desktop

On Wed, 2008-03-26 at 20:29 -0400, Jesse Keating wrote:
> On Wed, 2008-03-26 at 15:12 -0600, Gian Paolo Mureddu wrote:
> > Sarcastic disclaimer.
> >
> > Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be
> > done with it, then? Why EVEN have another path, anyway? Better yet, why
> > don't we follow Ubuntu and make sudo the default, make regular users
> > have admin rights! Why do we even need root? What's that? Geeze, I mean
> > why even keep an ancient file system layout?
>
> Believe it or not, these are all pretty useful suggestions.
>
> Links to (/usr)/sbin can be maintained for legacy or FHS compliance.
> However due to shortcomings in RPM this isn't feasible. Instead we'll
> just munge the normal user's path so that (s)he doesn't have to go
> hunting for useful tools.

Hm. Most of the commands found in {/usr,}/sbin only make sense for a
user with elevated privileges, i.e. root. Those that also make sense for
normal users (e.g. tools which provide read-only access as well like
ip/ifconfig, sysctl, etc.) could easily be hardlinked into the bin
directories on the same level without much hassle on the RPM side of
things.

> Sudo should (optionally) be the default for the first user added, like
> say through firstboot. A checkbox that would have to be cleared that
> will drop the user in the wheel group which by default has sudo rights
> (that way we don't have to munge the sudors file).

Sudo is all fine and dandy if you think about the command line, but this
is still a "legacy" way of doing things. Mind that as long as they're in
good order I'm all for keeping "legacy" as "legacy" often also means
"tried and true". I also don't see a reason why "legacy" and new ways
can't coexist.

> "root" is a legacy concept. Either the local user is also the admin, or
> the admin is a site wide admin where local root accounts are just jokes
> and instead things are done as sudo, or through config management
> systems.

"root" is only a legacy concept inasmuch as UIDs are seen as users, not
as roles that someone assumes temporarily, e.g. by way of sudo or
PolicyKit/dbus proxies. Keeping the privileged role separate from the
normal role, even for the primary user of a system, is one line of
defense against malware.

> I also agree that ancient filesystem layouts are needless confusion.
> They (almost) made since way back in the day, but fear of chance has
> kept them coming forward into modern day operating systems where they're
> just not needed, and only add confusion and frustration. "Where do I
> install this binary into? What level man page do I give this?" etc...

Man pages are a particularly bad example, as it's not only "What level
man page do I give this?" but also "What level is this man page I want
to read?" -- "man foo" almost always displays the wrong one if there are
multiple.

Other than that, the distinction and compartmentalization between /
and /usr is quite sound -- the former contains the basic set of tools
and libraries to bootstrap the system, regardless of where from the rest
comes. If disaster strikes, a small root volume is much less likely to
be than a giant single volume and it gives me the tools necessary to
salvage what is salvageable.

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 03-28-2008, 01:32 PM
"Horst H. von Brand"
 
Default few ideas how to make fedora better as a desktop

Bill Nottingham <notting@redhat.com> wrote:
> Jonathan Underwood (jonathan.underwood@gmail.com) said:
> > > Because it's changing 500 packages, and you can't do the replacement
> > > sanely in RPM anyway.
> >
> > Surely a large proportion of those 500 packages will be rebuilt in the
> > F-10 release cycle anyway? However, I don't understand the second
> > point you make there?
>
> To do a full /sbin -> /bin migration, you'd need to:
>
> 1) Rebuild all packages to change paths
> 2) Maintain a list of things that are commonly referenced by third-party/local
> scripts by path
> 3) Build a package that provides those symlinks
>
> I fail to see how this is more efficient than just modifying $PATH. (Actually
> I fail to see what horribly necessary commands are causing this to be a
> big issue, but that's beside the point.)

Most programs in sbin won't work for a regular user, anyway.

It is much easier to set up the first/only user with the adequate PATH, and
leave it there.

The sbin vs bin distinction is useful on servers. It has a /very/ long
history by now, so changing that isn't easy.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 03-28-2008, 01:55 PM
"Horst H. von Brand"
 
Default few ideas how to make fedora better as a desktop

Shawn Starr <sstarr@platform.com> wrote:

[...]

> The LSB is useful for commercial distributions not really for free
> distributions. I don't see commercial vendors releasing software for
> Fedora because it changes too much, they can't test against it changing
> every 6 or so months. I experience this every day here at my place. 3rd
> party vendors do not like rapid changes especially mathematical
> applications that are particularly sensitive to GCC optimizations, GNU
> libc, and GNU libstdc++ changes. The LSB doesn't go far enough to
> guarantee such it only gives a ABI/API compatibility. This becomes
> critical when your math library is off by 0.06 fractions, ask FLUENT
> this.

On commercial distributions it matters for consistency from one version to
the next, and across distributions.

On free distributions it matters for consistency with the commercial branch
(one of the reasons for me to use Fedora is consistency with RHEL/CentOS).
Also, it is important for people who build their own software. The most
irritating differences between systems are precisely the minor, gratuitous
ones. Thus FHS and such.

[Yes, I did live through the hell of SunOS to Solaris (BSD style to
SysVr4), and stuff like changing paths and minor differences in command
syntax were the worst of that. Plus the mess of futzing around with the
configuration of software resetting installation paths until upstream
catched on.]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org