Access 2007

[David W. Fenton]

in message:


I believe it's only for the ACCDB file format David.

I'm actually not surprised about that, but it's disappointing,
nonetheless. Better encryption would have strengthened Jet ULS -- we
couldn't have that, I guess!

 

[Jeff Conrad [MSFT]]

in message:

I'm actually not surprised about that, but it's disappointing,
nonetheless. Better encryption would have strengthened Jet ULS -- we
couldn't have that, I guess!

You'll get no argument from me on that one!

--
Jeff Conrad - Access Junkie - MVP Alumni
SDET - XAS Services - Microsoft Corporation

Co-author - Microsoft Office Access 2007 Inside Out
Presenter - Microsoft Access 2007 Essentials
http://www.accessmvp.com/JConrad/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com

 

[Guest]

I mentioned in a previous post (different thread) that I could see putting
together my on security model for the very purpose that David Fenton
describes but that's what was/is so nice about ULS (as I saw it anyway). One
less thing for me to deal with! I'm interested to know why you say it would
be easier to develop and maintain my own vs. ULS. Where can I find more
information on doing just that (bare with me...I'm somewhat of a newbie!)?
I was just about to add approx. 20-30 additional user's to my project (split
db with distributed runtime-only clients), each of whom would have differing
needs from the data and application, hence the desire to control application
elements at group and individual levels, and I now understand that I can
continue under the .mdb/.mde formats. My plan had been to eventually upsize
the backend to SQL Server while retaining the ULS for application
control....works great now. It would be nice to know, though, what I may be
up against in future development and support. Any insight you can provide
would be greatly appreciated!

--
philman

If you need to protect the data from non-users then use network
security. If you need to protect the data from users then don't
store it in an Access/Jet file. Use a server database with real
security.

This has always been true. Access 2007 is just making it clear
that Microsoft admits to that truth.

Yes, but it ignores a very important use for ULS, which is
conditional access to application functionality based on user group
membership. [snip]

Agreed, but implementing ULS just to assign conditional access at a group level
is (to me) paying ten dollars for a coke. Rolling your own for that is not only
easier than ULS, but WAY easier to maintain.

 

[Guest]

Sorry, I meant to say "continue under the .mdb/.mdw formats" (the project was
developed under 2003). And to further clarify, my intention was to
eventually upsize the back-end to SQL Server while retaining Access, and ULS
for application control, for the front-end.

--
philman

I mentioned in a previous post (different thread) that I could see putting
together my on security model for the very purpose that David Fenton
describes but that's what was/is so nice about ULS (as I saw it anyway). One
less thing for me to deal with! I'm interested to know why you say it would
be easier to develop and maintain my own vs. ULS. Where can I find more
information on doing just that (bare with me...I'm somewhat of a newbie!)?
I was just about to add approx. 20-30 additional user's to my project (split
db with distributed runtime-only clients), each of whom would have differing
needs from the data and application, hence the desire to control application
elements at group and individual levels, and I now understand that I can
continue under the .mdb/.mde formats. My plan had been to eventually upsize
the backend to SQL Server while retaining the ULS for application
control....works great now. It would be nice to know, though, what I may be
up against in future development and support. Any insight you can provide
would be greatly appreciated!

--
philman

If you need to protect the data from non-users then use network
security. If you need to protect the data from users then don't
store it in an Access/Jet file. Use a server database with real
security.

This has always been true. Access 2007 is just making it clear
that Microsoft admits to that truth.

Yes, but it ignores a very important use for ULS, which is
conditional access to application functionality based on user group
membership. [snip]

Agreed, but implementing ULS just to assign conditional access at a group level
is (to me) paying ten dollars for a coke. Rolling your own for that is not only
easier than ULS, but WAY easier to maintain.

 

[Rick Brandt]

I mentioned in a previous post (different thread) that I could see putting
together my on security model for the very purpose that David Fenton
describes but that's what was/is so nice about ULS (as I saw it anyway). One
less thing for me to deal with! I'm interested to know why you say it would
be easier to develop and maintain my own vs. ULS.

Access ULS is just a PITA to set up and deal with (again IMO). To me, it was
worth it when it was (thought to be) unbreakable. Once it became fairly common
knowledge that it could be easily defeated I never used it again.

Where can I find more
information on doing just that (bare with me...I'm somewhat of a newbie!)?

I just use a User's table with one column being the Windows Login and other
columns being additional stuff I want to know about a user (Email address,
FirstName, LastName, etc.). Then I have a companion table (1 to many) that
stores permission codes. The last piece is a user defined function that
returns true or false given permission code as an argument.

I grab the windows login at startup using the standard API code and from that I
know what "user" I am dealing with for the remainder of the app's operation.
Any place I want to limit access I can simply use...

If Permission("PermCode") Then
'code to let them in
Else
'code to deny them
End if

I have a utility form that makes it very simple to see all users having a
certain permission code and also to see all permission codes assigned to any one
user (and make any changes).

Now, in an all-jet system a user with know-how could give himself a permission
code he should not have. In my case though all tables are on SQL Server or an
IBM ISeries and it is the security on those servers that really controls stuff.
The perm-code system in the front end just allows me to deter users with more
user-friendly handling than server error messages would.

BUT...even though my system is not bullet proof in an all-jet scenario we now
know that ULS would not be either and my system is a breeze to set up and manage
compared to ULS. So, if one is only using ULS as a way to provide user access
"guidance" then I consider it too much work for the task.

I was just about to add approx. 20-30 additional user's to my project (split
db with distributed runtime-only clients), each of whom would have differing
needs from the data and application, hence the desire to control application
elements at group and individual levels, and I now understand that I can
continue under the .mdb/.mde formats.

A system like mine would not care which file format you used.

My plan had been to eventually upsize
the backend to SQL Server while retaining the ULS for application
control....works great now. It would be nice to know, though, what I may be
up against in future development and support. Any insight you can provide
would be greatly appreciated!

ULS for application control certainly works. I just think that management is
overly complicated, especially when talking about creating all new
groups/categories. My system does that in seconds and requires no MDW file
updates or that particular MDW files be used.

The one advantage that ULS has always had is that it establishes willful intent
on those that break it. With most home-grown systems a user could back door you
and then claim later (if discovered) that it was an innocent mistake ("I had no
idea I wasn't supposed to import/link those tables from a separate file").
While ULS can be circumvented anyone doing so would NOT be able to claim that it
wasn't a willful act specifically intended to gain access where they should not
have it. This is the "lock on a screen door" effect. Sure they can still put
their fist through the screen, but they better make sure they aren't caught
doing so.

So, for someone wanting to "secure" an all-jet app to the degree that it is
possible then I agree that ULS is still the way to go. For "friendly guidance"
in an app where security is either not the real concern or where it is
controlled elsewhere (a server back end) then I think that ULS is overkill.

 

[Chris Mills]

Shouldn't it be "Alumnus"? The singular?

I'm just having a bit of fun Jeff, it is GREAT for us when a former MVP now
works for MS, because we can be fairly certain the alumnus at least empathises
with us poor developers! (?) (empathises is not a plural...I think...)

Just as well you never put alumna/alumnae (female version?) <g>
-----
But to get serious,
I have this blog sent to me by a colleague (I do not have the original URL). I
think it is self-explanatory, if we are take it as true?

Or regardless, as a co-author of some A2007 educational stuff, can you also
point us to some URL's (yep, I'm a miserable b'tard when it comes to money!)

Best Regards
Chris

(you might see this as a back-hander, but I AM congratulating you on
representing MS!)

------------------------------------

re: Access Runtime is on Hold
Friday, June 29, 2007 7:56 PM by John F. Cantrell
This is just indicative. Good intentions aside (and no one is casting
aspersions against individuals here), the fact that the web page mentions
Access's "improved interface" is symptomatic of the quiet disaster of Access
2007. Maybe (maybe) if you are a Visual Studio developer who has always
looked askance at the Access control surface you might accept such a
characterization. But the rest of us...? What a mess! Add in the Access 2003
crash issue (which occurs on closing after module editing and has apparently
never been fixed in public service releases, but which you may call to get a
fix for... what's up with that?) and one gets the impression that Microsoft
has lost its way with or its commitment to this product, or the internal
politics and the lack of defensive clout of the Access team have
diluted/blurred Microsoft's focus on the special characteristics of Access
that have made the tool so great over the years.

I have made my entire living for 14 years exclusively with Access and am
incredibly grateful to Microsoft for it. A hearty THANK YOU to every one
responsible for it at Microsoft.

Luckily my living (entirely from Access, mind you) has been so good that I am
able to retire soon. Thank goodness I don't have to look at a future of
trying to work with Access 2007 and its descendants. Not all of the hours
spent on a project are ethically billable.

I'm building my last project now... using Access XP.

 

[Chris Mills]

Agreed, but implementing ULS just to assign conditional access at a group
level

is (to me) paying ten dollars for a coke. Rolling your own for that is not only
easier than ULS, but WAY easier to maintain.

If one is familiar with ULS, as we would be after a few years of interim
struggle, I'd describe it as a "coke".

Whether ULS or Roll-Your-Own, both require significant "development" and
thereafter one essentially "copies what one has learned" to any new app. The
effort is, in that case, minimal. Here you are suggesting that developing a
whole brand-new Roll-Your-Own (which for many of us would be a new
development), is a "coke"?

Chris

 

[Guest]

Thanks so much for the info. Your approach seems more than adequate for my
application. I'm just sorry that I'm so late to dance, so to speak. It
would have been nice to lend my voice during the beta release. There must be
literally thousands of applications out there that have been developed, sold,
and implemented using nothing more than ULS. I find it hard to believe that
it wasn't retained and improved rather than left behind (the whole "backwards
compatability" thing aside....anytime I hear that, I get concerned....that
usually means to not count on it being there for much longer). I'll be
watching much more closely just to see where things go from here.

 

[David W. Fenton]

I mentioned in a previous post (different thread) that I could see
putting together my on security model for the very purpose that
David Fenton describes but that's what was/is so nice about ULS
(as I saw it anyway). One less thing for me to deal with! I'm
interested to know why you say it would be easier to develop and
maintain my own vs. ULS. Where can I find more information on
doing just that (bare with me...I'm somewhat of a newbie!)? I
was just about to add approx. 20-30 additional user's to my
project (split db with distributed runtime-only clients), each of
whom would have differing needs from the data and application,
hence the desire to control application elements at group and
individual levels, and I now understand that I can continue under
the .mdb/.mde formats. My plan had been to eventually upsize the
backend to SQL Server while retaining the ULS for application
control....works great now. It would be nice to know, though,
what I may be up against in future development and support. Any
insight you can provide would be greatly appreciated!

It occurs to me that, since a System.mdw is just a special kind of
MDB, why couldn't you use it to store your group membership data,
and read that information from it via DAO in an ACCDB?

Is that a crazy idea?

It would mean you didn't have to build it yourself, and if you're
only using it for group membership, it wouldn't be a problem for
security, etc.

 

[David W. Fenton]

I'm just sorry that I'm so late to dance, so to speak. It
would have been nice to lend my voice during the beta release.
There must be literally thousands of applications out there that
have been developed, sold, and implemented using nothing more than
ULS. I find it hard to believe that it wasn't retained and
improved rather than left behind (the whole "backwards
compatability" thing aside....anytime I hear that, I get
concerned....that usually means to not count on it being there for
much longer). I'll be watching much more closely just to see
where things go from here.

Some decisions about the future of Access are made not because of
the needs of Access users and developers, but because of MS's
corporate agenda. The future is Sharepoint and SQL Server and MS
took replication and ULS out of ACCDB in order to promote the use of
those products for those who need replication and ULS.

And, yes, it's bloody stupid of them to do that.

 

[Chris Mills]

$149 to get into SQL Server. Instant, not even brute force.

I think the focus is wrong. Real Security depends more on "environmental
conditions" (network security, physical security, file open exclusive so not
copyable while in use...)

For a "shrink-wrapped" app (ie passed out god-knows-where), what's the
difference? $149!

Chris

 

[Chris Mills]

Access ULS is just a PITA to set up and deal with (again IMO). To me, it
was

worth it when it was (thought to be) unbreakable.

So what about the $149 to break SQL Server? Is this just an "inconvenient
fact", best ignored?

Alright, maybe I exaggerate...
$149 (less $10 one would have spent to break Access) = $139.
+ a slight more knowledge for SQL Server (eg an off-line copy, floating around
your computer room or God Knows Where on tapes whatever) = +$100.
-Or an Access Front End, with a user already authorised for the data? (What do
YOU use for a Front End?)

Certainly, Security requires THINKING. Maybe I think too much.
Chris

 

[David W. Fenton]

So what about the $149 to break SQL Server? Is this just an
"inconvenient fact", best ignored?

Alright, maybe I exaggerate...
$149 (less $10 one would have spent to break Access) = $139.
+ a slight more knowledge for SQL Server (eg an off-line copy,
floating around your computer room or God Knows Where on tapes
whatever) = +$100. -Or an Access Front End, with a user already
authorised for the data? (What do YOU use for a Front End?)

Certainly, Security requires THINKING. Maybe I think too much.

I have always felt that the greatest security threat is not
strangers, but the employees who have to have authorization to use
your data. That's part of my discussion of security with any new
client -- you can do all you want with passwords and user
permissions, but if you can't trust the people you give access, then
it's all for naught.

Security is a *people* problem, not a *technology* problem.

 

[Chris Mills]

That struck me as well said!
Perhaps I would have preferred "not JUST a *technology* problem".

Furthermore, Scott's suggestion in this thread of investigating SQL Server
Express seems perfectly reasonable, on the blurb available. Of course, as a
replacement for Jet, not really for Access, which here remains the Front End.
(reasons like Performnce/Scalability, but not really just for security, it
seems to me)
(If technical security is a REALLY serious issue, I guess stuff should be
written in C++ or similar. Or, web-based where the only Front End is Internet
Explorer)

On FCI - "Fenton's Crazy Idea" (hey your words <guffaw>), I wasn't quite sure
if you meant "using the existing system table structures of system.mdw", or
just a place to hide your own stuff.

If the latter, I guess there are many "obfuscation methods". Separate db's
where "god-knows-what is stored", seems as good as any. QBuilt has or had one
example. Interestingly, "Roll-Your-Own" has had a very hard time (except for
smokers), until, that is, A2007 has forced the concept to the forefront again?
I have always thought that "Roll-Your-Own" has the advantage that, to put it
bluntly, it wouldn't be worth some international hackers time to break my
poxy-little-program-with-few-users. Most anyone in this ng could break any
obfuscation I design? Sure, but this is a "relatively expert ng", with limited
attention-span to the general public, and I sure don't want this ng as
customers that's for sure!

If the former, (utilise the existing system files, or so I interpreted), I
imagine that would require a spectacular understanding of the actual table ins
and outs, and traps, which probably only the "michkas of this world" may have.
(basically you'd need "Developer Team" type of knowledge, no?)
Not Impossible. But by the time the likes of me understood "system files"
sufficiently, it might just be faster to write my own (system tables)? If that
wasn't your intent, then I'm not sure.
----------
Whilst it is often said that MS is trying to encourage "us" to SQLServer by
(removing half of Access Security), (and I have no data to make arguments), it
nevertheless seems that MS Blurb (granted about as reliable as my fishing
claims) suggests MS-Access is Alive, Well, and Progressing? Why would they say
that if it is not their intent?
----------
MS also says SQLServer has "the most unit-installations", things like that. MS
quotes independent consultants. "More than Oracle and IBM combined!". The 2003
report I was reading was perfectly true, by the chosen measures. By another
measure in the same independent report (obtained from MS site), actually
indicated Oracle had well over 40%, IBM 20% or something. Aww Hell...we all
know salesmen BS, ALL of them, with true statistics to prove it.

 

[Chris Mills]

I would also like to say (before I upset Rick too much <bg>)(no-one has yet
<vbg>) that he has made a VALIANT attempt to explain his birds and bees.

(Which, by my reading, is essentially "Roll Your Own". That some of the stuff
is stored in SQL Server seems irrelevant ($149!). That his method is
relatively complex, and undoubtedly well-thought-out, is all kudos to Rick!

I remain with the lasting impression, not necessarily from Rick but the ng,
that designing "Roll-Your-Own" (no doubt in conjunction with the inherent
stuff) has been actively discouraged in this newsgroup to the extent of
derision. Before recently. Now it seems "flavour of the month" "the worms are
coming out of the woodwork to claim they had "roll your own" all along...

I have always thought that anything one can do (basically obfuscation) must
help, to an extent we can argue forever over? But, unlike some others, I took
the claims of the so-called "experts" seriously, the ones who claimed
"roll-your-own" was pointless. I never implemented any such schemes (at this
date), merely thought about them. Now, apparently, it's suddenly become all
the rage? The "In Thing"? Flared Trousers?

And this confusion about the merits of "roll-your-own" apparently extends to
the likes of "Gunny". Who sought an apology from me some months ago for saying
QBuilt promoted some RYO stuff, before I pointed out that they indeed did
exactly that! Did and do I have better suggestions than RYO? For the record,
no I support valiant attempts at RYO. Rick has indicated, at the least, a
reasonable amount of thinking about this?

Chris