SCC 7.4.1 can't see my USB drives?

[snarlydwarf]

I agree it does not make any remote sense the way it is set up right now for Ubuntu installs... the fact you install software via your regular admin id and that then it needs a special system permission seems pretty unique to SBS, my assumption is certain 9.10 release adjustments (Linux kernel? Gnome?) have not been made in the SBS software.

It's nothing special to SBS for that. MANY packages install their own user id for permissions purposes.

The 'odd' thing is that Ubuntu wants to play sort of like Windows: when you plug in removable "you" get to use it to copy files, etc.

The problem is that it isn't "you" that needs to read the drive, it is SBS. This is a different user ID than you.

Likewise, the loading of an external drive may be delayed until a user logs in so that it knows who to assign it to.

And for extra fun, your drive may be NTFS and not really happy with having Unix permissions.

I don't use Ubuntu, I'm a hardcore debian user, and my SBS server has no display, so no gnome.. I just put the USB drive in /etc/fstab and it's mounted at boot. The files/directories on that drive are owned by me and readable by 'world', so SBS has no problems with it. It is, of course, ext3s, since I don't care if Windows can read it.

[pablolie]

It's nothing special to SBS for that. MANY packages install their own user id for permissions purposes.

The 'odd' thing is that Ubuntu wants to play sort of like Windows: when you plug in removable "you" get to use it to copy files, etc.

The problem is that it isn't "you" that needs to read the drive, it is SBS. This is a different user ID than you.

Likewise, the loading of an external drive may be delayed until a user logs in so that it knows who to assign it to.

And for extra fun, your drive may be NTFS and not really happy with having Unix permissions.

I don't use Ubuntu, I'm a hardcore debian user, and my SBS server has no display, so no gnome.. I just put the USB drive in /etc/fstab and it's mounted at boot. The files/directories on that drive are owned by me and readable by 'world', so SBS has no problems with it. It is, of course, ext3s, since I don't care if Windows can read it.

The SBS-Ubuntu combo never had this issue (which has popped up with alarming frequency in the last 2 months) before the 9.10 and 7.4.1 mix though. I never had to struggle with permissions before - the issue was about mounting the USB drive. Once it mounted permissions were OK. In 9.10 and 7.4.1 suddenly there was the added permissions element.

My experience has been with an NTFS drive, hence my ntfs-settings pointer before; and I can not talk about other configurations. I know many moons ago as a newcomer to Ubuntu (and the thread is probably in the archives somewhere) I had issues with the Seagate drive I still use because there was a well-documented issue at the time, but that has been fixed since.

I do think that the whole volume mounting thing with Ubuntu is a major issue, and the Ubuntu forums speak volumes on the issue. It is a major problem standing in the way of wider adoption because it is a major first hurdle. Then come other issues (scanners, webcams etc).

And the solution seems to be slightly different based on the system flavor, which is not a good thing either.

As to permissions, and package that is installed by the admin id ought to be smart enough to make sure that sufficient resource permissions are awarded to it for system wide operation. Otherwise the installation procedure can only be regarded as buggy.

[snarlydwarf]

As to permissions, and package that is installed by the admin id ought to be smart enough to make sure that sufficient resource permissions are awarded to it for system wide operation. Otherwise the installation procedure can only be regarded as buggy.

That's not how Unix permissions work.

root installed apache2... but it is owned by www-data.

Unless i go to the effort to change permissions on /var/www or create a directory named 'public_html' with the proper permissions, I won't have any web pages... I need to configure the server and the file system to match my security model. (ie, root should -NOT- own web pages, a user should, and in many cases, -not- www-data.)

SBS's installation from a .deb has no clue where your music library is. That is set by the user later, It should not willy-nilly be guessing "oh, you have an external USB drive,let me change permissions on it!"

That would be a huge violation of debian security policy

[pfarrell]

snarlydwarf wrote:
> pablolie;495755 Wrote:
>> As to permissions, and package that is installed by the admin id ought
>> to be smart enough to make sure that sufficient resource permissions are
>> awarded to it for system wide operation. Otherwise the installation
>> procedure can only be regarded as buggy.
>
> That's not how Unix permissions work.

For good reasons.

@pablolie, the "make it work system wide" is the root cause of many of
the Windows malware problems that have cursed the industry. Adopting
those mistakes for good OS is a really bad idea.


> SBS's installation from a .deb has no clue where your music library is.
> That is set by the user later, It should not willy-nilly be guessing
> "oh, you have an external USB drive,let me change permissions on it!"
>
> That would be a huge violation of debian security policy

But, while I agree that the current Debian policy is right, Ubuntu is
trying to be all things to all people coming over from Winders. These
people have no clue what a decent security policy is.

And to be fair, the introductory documentation that the tiny percentage
are likely to find won't point all this out.

Ubuntu 9.04 and later 9.10 added a bunch more aparmour stuff, which
futher muddies the security/permissions waters.

I think a more fundamental problem is showing up here. In the olden
days, only geeks ran Linux, be it RedHat, Debian, etc. And the hacker
ethos at SlimDevices said "sure, its perl, it runs on whatever you have"

But as the SqueezeBoxen are moved more mass market by Logitech, and as
Ubuntu is pushed as more acceptable in the tech media, there are going
to be ever more users who are first time users with Ubuntu or similar
distros. And its just not going to be plug and play for 90% of them.

The only way out of this that I can see is for Logitech to put a ton
more effort into the setup scripts and documentation for all the
zillions of combinations of distros and hardware. I don't see this
happening. I would expect that Linux support will stop before they can
put that much effort into it.



--
Pat Farrell
http://www.pfarrell.com/

[probedb]

Here's a temporary solution...

I have my music folder rsync'd onto a USB drive that is attached to my sheevaplug, and I was having the same problem as you, where SB Server could not see any of the music. I ran the following command on my music folder:

chmod 777 -R music-folder/

So this pretty much makes the file / directory wide open, permissions wise. It seems to be working though. The only bummer is that I plan on getting the rsync to run nightly to update music on the device, and one of the beauties of rsync is that i only syncs files that have been modified or changed. I'm wondering now after doing this big chmod if all of the files are going to be re-written next time I do an rsync.

So at least I have my music playing throughout the apartment on my SB Radio. That's a relief, but this isn't a very elegant solution. So I'm hoping someone can find me a better one soon! Thanks!

Unfortunately this won't work for mine as the permissions are locked. Amusingly enough it's only the directories that aren't given group/world permissions as all the files are 777!

chmod 755 <directoryname>

does nothing to the directory itself!

That's also the reason why the adding the sbs user to a group doesn't work, the directories have no group permissions therefore only root and the user can see the folders

[pablolie]

That's not how Unix permissions work.

root installed apache2... but it is owned by www-data.

See https://help.ubuntu.com/community/RootSudo

My understanding is that indeed you should never, ever do anything as root. There are several system folders that are and should be locked for any user other than root on the system, for good reasons. And no human user should be root. Ever. I have not advocated anywhere messing around with root, quite the contrary, the fact that in thne end we are forced to dabble around with gksudo nautilus (or as yours may go) shows that there is something broken with the way it is implemented anyhow, because you force users into a basic violation of your sacred security policy to get a plain vanilla system going.

What I stated was something different: let us say user (or let us say "account") "pablo" is the main admin with the most privileges on a machine (mind you, he'd still never get access to root according to Ubuntu policies, in theory, but of course we know that is only a gksudo command away. The account maps to a user ID which belongs to a group. If user/account pablo installs SBS, the account/group's privileges should be propagated to the installed software automatically. It does not make sense to do it any other way. If my account can access a USB drive, the software I install should be able to access that drive too. Anything else it utterly unintuitive.

SBS's installation from a .deb has no clue where your music library is. That is set by the user later, It should not willy-nilly be guessing "oh, you have an external USB drive,let me change permissions on it!"

There is a big difference with configuration of settings (which naturally the user must do) and access to system resources. When a user installs a software package, the software package should have access to the resources the user has naturally access to. There is no added security in restricting a software packages capabilities. It's just inconvenient and utterly user unfriendly. "What, Photoshop doesn't get access to my picture folder?"

That would be a huge violation of debian security policy

I do not believe that. The security policy is concerned with protecting root directories, for very good reasons. A user installed USB drive merely hosting music or picture files is not a protected OS resource once mounted to the user's liking. If and when a root directory exists on the USB drive, then by all means that can (and is) protected. But anything I as a user mount to my /home/media...whatever, it should be there for every application I have the right to start. Anything else is confusing and simply not an intuitive security policy.

The whole idea of Linux security is to protect root resources from malicious (or unintentional) attack. That principle is not violated by propagating user access rights to resources to software those users install, since in Ubuntu they are not root in any normal operation (it seems you run your system differently, and more power to you, mind you).

[probedb]

I think we're getting off topic here.

The underlying issues I have with sbs are:

1. It is now installed and run as it's own user rather than root, this causes the second problem

2. Automounted drives (directories only) are not given any group or world permissions therefore the new sbs user cannot see them.

It's these two combined that are causing my problems with it. That said I'm now having issues with database access anyways.

If only the players supported DNLA as Twonky runs without issue and can see my drives

[snarlydwarf]

My understanding is that indeed you should never, ever do anything as root. There are several system folders that are and should be locked for any user other than root on the system, for good reasons.

Oversimplistic view. I have a dozen web/mail/svn/firewalls and such and am routinely root. It is difficult to change configurations when you're not root. (And, again, these are servers: X as root is bad.. an xterm as root is not. They don't even have X installed on them.)

gksudo, sudo, su, whatever.. they all make you root.

And no human user should be root. Ever. I have not advocated anywhere messing around with root, quite the contrary, the fact that in thne end we are forced to dabble around with gksudo nautilus (or as yours may go) shows that there is something broken with the way it is implemented anyhow, because you force users into a basic violation of your sacred security policy to get a plain vanilla system going.

I would agree that the pretty UI that Ubuntu insists on giving you is broken: it should be possible to mount an external drive as part of the boot process. For some things, you may just have to break down and do it by hand, though, I don't use ntfs so no interest in figuring out how to make it behave correctly with permissions, which is your problem.

What I stated was something different: let us say user (or let us say "account") "pablo" is the main admin with the most privileges on a machine (mind you, he'd still never get access to root according to Ubuntu policies, in theory, but of course we know that is only a gksudo command away. The account maps to a user ID which belongs to a group. If user/account pablo installs SBS, the account/group's privileges should be propagated to the installed software automatically. It does not make sense to do it any other way. If my account can access a USB drive, the software I install should be able to access that drive too. Anything else it utterly unintuitive.

And I disagree: SBS has its own user id so that YOU can tell it what files it may access.

There is a big difference with configuration of settings (which naturally the user must do) and access to system resources. When a user installs a software package, the software package should have access to the resources the user has naturally access to. There is no added security in that. It's just inconvenient and utterly user unfriendly.

So when i, as 'bem' install apache, apache should have access to all my files? I think not.

I do not believe that. The security policy is concerned with protecting root directories, for very good reason. A user installed USB drive is not a protected resource. If and when a root directory exists on the USB drive, then by all means that can (and is) protected. But anything I as a user mount to my /home/media...whatever, it should be there for every application I have the right to start. Anything else is confusing and simply not an intuitive security policy.

Then you have a beef with Ubuntu which is setting that permission.

The whole idea of Linux security is to protect root resources from malicious (or unintentional) attack. That principle is not violated by propagating user access rights to resources to software those users install, since in Ubuntu they are not root in any normal operation (it seems you run your system differently, and more power to you, mind you).

Wrong: it also involves protecting users from accessing other users files except when desired and keeping processes contained so that they do not easily violate rules and leak information from one user to another or to the network.

Not every desktop machine has a single login.

I have machines with -thousands- of logins, and making sure that 'jsmith' does not read the email of 'jdoe' is crucial. Ensuring they do not read or write each others web pages is critical.

In a 'desktop' configuration, perhaps it is "okay" to do what you wish, but that, again, is a matter for Ubuntu.

SBS does -NOT- mount your drive, it does NOT enforce permissions on your drive: the kernel does, and it does so with the guidance that Ubuntu has when seeing new removable media.

[probedb]

I would agree that the pretty UI that Ubuntu insists on giving you is broken: it should be possible to mount an external drive as part of the boot process. For some things, you may just have to break down and do it by hand, though, I don't use ntfs so no interest in figuring out how to make it behave correctly with permissions, which is your problem.

Then kindly leave this thread as that's it's entire point or I'm going to ask a mod to lock it!

[hungarianhc]

Then kindly leave this thread as that's it's entire point or I'm going to ask a mod to lock it!

No don't lock it, please! I use EXT2 for my external drives, but this is valuable conversation!!! Have we figured out a "best practice solution" btw? I really hate my implementation of chmod'ing the files. Is there an fstab setting that will make everything all better?